多次元データベースアーキテクチャ

专利摘要:
情報処理システム、特に、データベースにおけるデータの格納及びデータベースからのデータ検索を容易にするコンピュータに実施されるデータベース及びデータベース管理システム（ＤＢＭＳ）を提供する。データベース管理システムは、異なるフォーマットの独立したコピーとして複数の論理テーブルからのデータを格納する。１つの特定の例では、システムは、テーブルをテーブル群に組織し、各テーブル群内のテーブルを非正規化する。それはまた、１つの属性に関する全てのデータを格納する垂直縦列容器を含む第２のフォーマットでデータを組織し、各テーブル及びそのテーブル内の各属性に対して縦列容器が１つある。コピーの受け取りにより、システムは、容器の組のいずれか又は両方と対話することができる問い合わせ計画を作成する。
公开号:JP2011510379A
申请号:JP2010542303
申请日:2009-01-06
公开日:2011-03-31
发明作者:オーリ ヘルンシュタット
申请人:オーリ ヘルンシュタット；
IPC主号:G06F12-00

专利说明:

[0001] 本発明は、一般的に、情報処理システムに関し、より具体的には、データベースにおけるデータの格納及びデータベースからのデータ検索を容易にするコンピュータに実施されるデータベース及びデータベース管理システム（ＤＢＭＳ）に関する。]
背景技術

[0002] 初期の簡単なデータベース構造では、複数の横列又はタプル、及び縦列から成る単一のファイル又はテーブルが含まれていた。このフォーマットは、各横列が固有であり、すなわち、データが冗長でなかった時に特に役に立つものであった。しかし、データベースは、たちまち複雑化したものとなった。各横列は、固有ではない情報を含み始めた。例えば、著者及び著者が書く本に関する情報を含むデータベース考える。著者が複数の本を書いた場合、簡単なデータベーススキーマ内の各横列は、著者の名前及び１冊の本の識別を含むであろう。従って、著者が「ｎ」冊の本を書いた場合、テーブルには「ｎ」個の横列が含まれ、著者の名前が、「ｎ」個の横列の各々に表示されると考えられる。]
[0003] 複数の横列における著者の名前のような同じ値のこの繰返しは、「冗長性」として特徴付けられる。冗長性は、ある一定の問題を招く。例えば、冗長なデータを格納すると不要にメモリが消費され、その時代は、メモリは制限されたものであり、かつ高価であった。この問題は、時の経過と共に最小にされた。しかし、最小にされていない問題には、データを変更するデータ更新及び一貫したデータを維持する必要性が関わっている。データベースに著者達及び彼らのアドレス、及び１人の著者のアドレス変更が含まれている場合、その著者が書いた各々の本に関する記録におけるそのアドレスを変更することが必要である。データ更新処理が何らかの理由で中断された場合、その著者のアドレスは、変更される場合もあれば変更されない場合がある。得られるデータは、一貫性がないものとなろう。データの一貫性を維持することは、現在のデータベースに関して必要とされるものである。]
[0004] 次に、関係データベース管理システム（ＲＤＢＭＳ又は「関係モデル」）が開発された。これらのシステムは、依然として従来技術のデータベース管理システム（ＤＢＭＳ）の基盤の役割を果たしている。１９７０年代に導入された関係モデルにより、形式的な代数と「構造化問い合わせ言語（ＳＱＬ）として公知である関連の宣言型問い合わせ言語とによりサポートされるデータ独立性が開拓された。この言語では、「ＳＱＬ問い合わせ」又は「問い合わせ」は、様々なテーブル中のデータと対話する１次ツールである。]
[0005] 一般的に、ＲＤＢＭＳシステムは、テーブル中の関係記憶スキーマに従ってデータを格納する。各テーブルは、ディスク、メインメモリ、及び他のメモリのようなデータ記憶機器内で横列の連続した組として格納される。多くのシステムは、特定の横列又は横列への高速ランダムアクセスを可能にするために更に別のデータ構造としてインデックスを実施する。インデックスにより、いくつかのキー値に基づく横列へのナビゲーションを容易にするように縦列又はいくつかの縦列（インデックスのキー）が符号化される。各インデックスには、データが変わった場合には、インデックスデータ構造を構築及び維持する追加コストが伴う。しかし、ユーザには、テーブルとしてデータの非冗長なビューが示され、ユーザは、一般的に、この及び他の潜在的な冗長性には気付かない。]
[0006] ２つの他の概念、すなわち、「正規化」及び「関係」も、この開発中に生まれた。「正規化」では、複数のテーブルにデータを分割することによって冗長性が最小にされる。上述の例では、単一の冗長な著者と本のテーブルを正規化すると、個々の著者テーブルと本テーブルが生成される。著者テーブルには、１回に１人の著者に関する情報が含まれ、本テーブルには、１回に１つの本に関する情報が含まれている。]
[0007] 図１は、論理形式で、各著者及び本に関する情報、及び複数の顧客の各々と、注文と、各々の注文に関連の本とに関する情報を記録する簡単な正規化されたデータベース３０を開示する。この情報のまとめには、個々のテーブルで「正規化された」データベースを定めるためにデータ情報の分析を含む。１つ又はそれよりも多くの個々のテーブルを関連付けることができる。例えばかつ説明上、データベース設計者が図１のこのデータを分析して、著者群３１、顧客群３２、及び州群３３のような関連付けられたテーブルの３つの群を任意に定めると仮定する。著者群３１は、著者及び本に関する全ての情報を含むと共に、著者テーブル３４及び本テーブル３５を含む。顧客群３２は、顧客及び注文に関すると共に、顧客テーブル３６、注文テーブル３７、及び品目テーブル４０を含む。州の群３３は、州情報に関し、州テーブル４１を含む。明らかなように、州群は、複数のテーブルを含むことができ、かつ品目テーブル４０は、著者群３１の構成群とすることができる。] 図１
[0008] 図１は、これらの個々のテーブルの関係を示すが、これらの関係は、明示的に定められているわけではない。むしろ、基本キー及び外部キーにより、関係を定めることができる情報が得られる。特に基本キー及び外部キーの命名に関しては、多くのフィールド命名規約がある。ここで説明する内容では、接頭辞「ｆｋ」は、別の関連のテーブルにおいて外部キー名を形成するために１つのテーブルの基本キー名に追加されると仮定する。この特定の例においては、著者テーブル３４は、ＡＵＴＨＯＲＩＤ基本キーフィールドを含む。本テーブル３５は、ｆｋＡＵＴＨＯＲＩＤ外部キーフィールドを含む。このような関係は、一般的に、１つ対多くの関係として説明され、その理由は、本テーブル３５の複数の横列の同じ外部キーが、各著者に関連付けられるからである。すなわち、単一の、すなわち、「１人」の著者は、１つ又はそれよりも多くの、例えば、「多くの」本と結合される。図１のリンク４２は、論理レベルで、ＡＵＴＨＯＲＩＤフィールド及びｆｋＡＵＴＨＯＲＩＤフィールドが定める関係を表している。] 図１
[0009] 図１の顧客群３２は、リンク４３及びリンク４６によって定められた類似の１つ対多くの関係を含む。２つのリンク４４及び４５は、異なる群におけるテーブル同士の関係を定める。リンク４４は、著者群３１内のテーブルを顧客群テーブル３２と結びつける。具体的には、品目テーブル４０は、ｆｋＯＲＤＥＲＩＤ及びｆｋＢＯＯＫＩＤの外部キーを有する。ｆｋＯＲＤＥＲＩＤ外部キーは、１つの注文を１つの品目と結びつける。ｆｋＢＯＯＫＩＤ外部キーは、１冊の本を１つの品目と結びつける。リンク４５は、顧客テーブル３６と州テーブル４１の関係を定め、顧客テーブル３６中のｆｋＳＴＡＴＥＩＤフィールドは、州テーブル４１中のスタットＥＩＤフィールドとリンクしている。] 図１
[0010] 図１は、「属性」とも呼ばれる一部の代表的フィールドを備えた各テーブルを示すが、図２は、データシート図で、横列、縦列、及び代表的データを備えたテーブルを示している。各テーブルは、基本キーを有し、一部は、外部キーを有する。より具体的には、著者テーブル３４は、著者の姓、名、生年月日、及び任意的な契約情報に関してＡＵＴＨＯＲＩＤ基本キープラス属性を含む。本テーブル３５は、タイトル、表示価格（リスト）、刊行日及び内容説明に関するＢＯＯＫＩＤ基本キー、ｆｋＡＵＴＨＯＲＩＤ外部キー、及び属性を含む。ここで説明する目的上、各本は、１人の著者だけにより書かれていると仮定する。残りのテーブル及び属性の構成は、当業者には明らかであろう。] 図１ 図２
[0011] ＳＱＬ問い合わせは、情報をデータベースに要求して、要請された情報の「ｒｅｓｕｌｔｓｅｔ」を作成する。「ｒｅｓｕｌｔｓｅｔ」は、メモリ内のデータのコピーを保持して、かつデータソースから切断されるオブジェクトである。最も一般的なＳＱＬ問い合わせ又は指令は、データを検索して、ＦＲＯＭ、ＷＨＥＲＥ、「ＧＲＯＵＰ ＢＹ」、ＨＡＶＩＮＧ、及び「ＯＲＤＥＲ ＢＹ」クローズを含む宣言型ＳＥＬＥＣＴキーワード及びいくつかの任意的なキーワード及びクローズで実行される。あらゆる問い合わせに対する応答は、異なるファイル位置から個々に各々の識別されたテーブルを検索しなければならず、次に、関係に従って異なるテーブルから対応する横列を適合させる。]
[0012] ＷＨＥＲＥクローズのコンテンツは、明示的に、要求に関連する各々の関係を定めて、「結合」演算の基盤の役目をする「非正規化」情報を提供する。ＷＨＥＲＥクローズは、関係をもたらすフィールド又は属性を具体的に定める。例えば、著者テーブル３４と本テーブル３５の関係を定義する必要があるＷＨＥＲＥクローズは、著者テーブル３４及びＡＵＴＨＯＲＩＤ基本キー及び本テーブル３５及びｆｋＡＵＴＨＯＲＩＤ外部キーを識別する。すなわち、そのＷＨＥＲＥクローズの実行により、各横列が著者の情報及び１つの本識別を含むオリジナルデータを再生するために、ＡＵＴＨＯＲＩＤ基本キー及びｆｋＡＵＴＨＯＲＩＤ外部キーを使用して２つのテーブルが結合される。問い合わせ応答は、解決する必要がある各々の関係に対して１つの結合演算を処理する必要がある。]
[0013] 効率的に結合演算を実行することは困難である。図１及び図２に示すそのような非効率性は、比較的小さいデータベースにおいて許容可能なものである。しかし、実際のデータベースは、益々複雑化している。顧客エンティティは、注文、品目、アドレス、電話、トランザクション履歴、及び他の家人とのリンクを含む情報の多くのレベルを含むことができる。正規化により、各レベルの情報が専用テーブルに置かれる。データベースが複雑な関係で多くのテーブルを有する時に存在する関係により、結合回数が増大する。図１及び図２に示すようなデータベースを超える大規模なサイズ及び複雑性のデータベースにおける結合演算非効率性の蓄積効果は、許容することができないものである。] 図１ 図２
[0014] 通常、データベースは、個々に又は組み合わせてディスク、メインメモリ、キャッシュ、及び他のメモリを含むデータ記憶機器内に格納及び処理される。各メモリは、待ち時間特性を有する。一般的に、「待ち時間」は、データ要求と実際のデータ転送開始の間に経過する時間である。ディスク遅延は、例えば、３つの成分、すなわち、シーク時間、回転待ち時間、及び転送速度を有する。シーク時間は、ディスクヘッドがアクセス中のディスクシリンダに移動するのに必要とされる時間の尺度である。回転待ち時間は、特定のディスクブロックがディスクヘッド下で到達するのに必要とされる時間の尺度であり、転送速度（帯域幅）は、データがディスクヘッド下で通過する速度の尺度である。連続したアクセスに対して、シーク時間及び回転時間の判断を行う必要があるのは、第１のデータブロックに関してのみである。]
[0015] 時の経過と共に、読取、書込の両演算に対して、ディスク及びメモリ帯域改良により非常に効率的な順次アクセスが可能となっている。しかし、ディスク及び記憶待ち時間は、対応して改善してはおらず、ランダムアクセスは、非常に非効率なものとなっている。待ち時間と比較した帯域内の大きな改善とは、順次アクセスがランダムアクセスより非常に「廉価」になっていることを意味する。更に、ランダムアクセスに勝る順次アクセスの性能上の利点は、時の経過と共に指数関数的に増大している。個々のテーブルへのアクセスでは、特に結合演算中、広範囲なランダムディスク及びメモリアクセスが必要である場合がある。各々が異なるテーブル中の別々の横列内に常駐する顧客エンティティの全ての部分にアクセスするには、多くのランダムアクセスが必要である。それによって結合演算、並びに他の問い合わせ演算を効率的に実行する際の困難度が更に増大する。]
[0016] ＳＱＬ問い合わせは、データベース対話アプリケーションの２つの群、すなわち、ＯＬＴＰ（オンライントランザクション処理）とＤＳＳ（意志決定支援システム）アプリケーションと最初に呼ばれていたＯＬＡＰ（オンライン分析処理）とにおいて使用される。ＯＬＴＰアプリケーションは、オンライントランザクションを処理する。このようなトランザクションに関連の情報は、従来の記憶スキーマを使用して、効率的に図１に示すうちのいずれか１つのような単一のテーブルに追加するか、又は単一のテーブルから検索することができる。しかし、エンティティが益々多くのテーブルに及ぶ時に、結合演算及びランダムアクセスの追加されたコストにより、このような問い合わせは、益々非効率なものになる。] 図１
[0017] 簡単な関係を備えた小さいデータベースに対して、ＯＬＡＰアプリケーションによる情報要求は、適切な効率で処理することができる。複雑なデータベースでは、ＯＬＡＰアプリケーションは、多くの横列を含むテーブル中の僅かに少しの縦列のみからのデータを検索、取り出し、及び集約する。各テーブルは、索引を付されないあらゆる次元に対して、又は予め計算されていないあらゆる集約に対して漏れなく走査する必要がある。従って、比較的複雑な関係データベースへのあらゆる解析的問い合わせにより、適切な時間に結果データセットを生成されることはありそうもない。]
[0018] 例えば、図３Ａは、特定の顧客に注文される各々の本に関してタイトル及び販売価格をリスト化しようとするＯＬＴＰ問い合わせ５０を示している。ＳＥＬＥＣＴクローズ５１は、各品目に関する１つの横列において、顧客テーブル３６から選択された顧客の姓名に関する最終結果データセット、本テーブル３５から本タイトル、及び品目テーブル４０から販売価格を定める。] 図３Ａ
[0019] ＦＲＯＭクローズ５２は、ＳＱＬ問い合わせ５０の実行中にアクセスすべき各テーブルを識別する。この特定の例においては、テーブルは、それぞれ、顧客テーブル３６、注文テーブル３７、品目テーブル４０、及び本テーブル３５である。]
[0020] ＷＨＥＲＥクローズ５３は、各テーブルから検索すべき横列を識別して結合を確立する。この例においては、第１の条件５４では、顧客テーブル３６中のＣＵＳＴＯＭＥＲＩＤ値は、注文テーブル３７中のｆｋＣＵＳＴＯＭＥＲＩＤフィールド内の値に等しいことが必要である。条件５５及び５６は、注文テーブル３７中のＯＲＤＥＲＩＤフィールドと品目テーブル４０中のｆｋＯＲＤＥＲＩＤフィールド内の値との間、及び本テーブル３５中のＢＯＯＫＩＤ値と品目テーブル４０中のｆｋＢＯＯＫＩＤフィールドとの間に類似の関係を確立して結合される。最終条件５７は、顧客テーブル３６中のＣＵＳＴＯＭＥＲＩＤフィールドが「２０」に等しいという基準を確立する。]
[0021] 公知でありかつ図４で論理的に示すように、データ処理システム５８は、ＳＱＬ問い合わせ５０の受信に応答して、ＳＱＬ問い合わせを構文解析、最適化、及び実行することによって最終ｒｅｓｕｌｔｓｅｔを生成する。問い合わせ構文解析プログラム５９は、データ辞書６０内の情報を使用して各ＳＱＬ問い合わせを一連のＳＱＬクラスに変換する。問い合わせ最適化プログラム６１は、ＳＱＬ問い合わせ及び問い合わせ構文解析プログラム５９から情報及びデータ辞書６０に応答して問い合わせ計画を生成する。実行ユニット６２は、問い合わせ計画及びデータ辞書６０及びデータストア６３からの情報を処理してｒｅｓｕｌｔｓｅｔを生成する。] 図４
[0022] 一般的に、データ辞書は、データの要素の定義及び表現を有するメタデータを含む。ＤＢＭＳの関連では、データ辞書は、１組のテーブル及びビューであり、データの要素の定義、ユーザ名、横列及び特権、スキーマオブジェクト、一体性に関する制約事項、蓄積手順及びトリガ、一般的データベース構造に関する情報、及び空間割り当て情報を保持する。この実施形態では、図４のデータ辞書６０は、１組６４のテーブルエントリを含む。組６４内の各テーブルエントリは、１組６５の属性又はフィールド定義を含む。組６５内の各定義は、各属性又はフィールドに関する１組６６の特性の組を含む。] 図４
[0023] 変更ログ６７は、全てのデータ挿入、削除、及び更新処理の耐久性を容易にするものである。公知のように、変更ログ６７のような変更ログは、ディスク又は光ドライブのようなあらゆるクラスの不揮発性記憶装置内のあらゆる変化を記録する。]
[0024] データベースシステムは、あらゆる処理システム内で作動してあらゆる数のコンピュータ、処理、スレッドなどを使用することができる。各アプリケーションは、性能又は他の考慮事項を満たすために、複数回再現又はインスタンス化することができる。更に、異なるシステムは、異なる方法で処理ＳＱＬ問い合わせを処理することができる。図３Ｂは、図３ＡのＳＱＬ問い合わせ５０に関する１つのこのような問い合わせ計画７０を示し、図３Ｃ及び図３Ｄは、実行ユニット６２が問い合わせ計画７０を処理した時に生成される中間及び最終の結果の組を示している。図３Ｂ及び図３Ｃを合わせて参照すると、最初に、段階７１は、ＣＵＳＴＯＭＥＲＩＤ値が「２０」である顧客テーブル３６中の記録を含む第１の中間ｒｅｓｕｌｔｓｅｔ７１Ａを定める。この第１のｒｅｓｕｌｔｓｅｔは、この特定の例においては、顧客テーブル３６からの記録を１つだけ含む。明らかなように、このような選択は、ＣＵＳＴＯＭＥＲＩＤ値を取得するように名前情報、この例においては顧客「Ａｄａｍ Ａｐｐｌｅ」に応答して行うことができる。] 図３Ａ 図３Ｂ 図３Ｃ 図３Ｄ
[0025] 段階７２は、ＣＵＳＴＯＭＥＲＩＤ＝２０に対応するあらゆる注文を識別するためにテーブル３７を走査する第１の結合演算を表している。従って、段階７２は、顧客データと共に、「Ａｄａｍ Ａｐｐｌｅ」に関連する注文テーブル３７からの各記録を含む第２の中間ｒｅｓｕｌｔｓｅｔ７２Ａを生成する。]
[0026] 第２の結合演算７３では、中間ｒｅｓｕｌｔｓｅｔ７２Ａ内のＯＲＤＥＲＩＤ基本キー値及び品目テーブル４０中のｆｋＯＲＤＥＲＩＤ値を使用して、「Ａｄａｍ Ａｐｐｌｅ」が注文した品目を識別する。第３のｒｅｓｕｌｔｓｅｔ７３Ａが生成される。第３の結合演算７４では、それらの横列を結合し、段階７３で、本テーブル３５からの対応する本により、段階７３Ａのｒｅｓｕｌｔｓｅｔ内のｆｋＢＯＯＫＩＤ外部キー値及び本テーブル３５中のＢＯＯＫＩＤ基本キー値を通じてｒｅｓｕｌｔｓｅｔを生成し、第４のｒｅｓｕｌｔｓｅｔ７４Ａを生成する。射影演算７５では、ＳＱＬ問い合わせ５０によって定められたように、この第４のｒｅｓｕｌｔｓｅｔ７４Ａを「Ａｄａｍ Ａｐｐｌｅ」が購入した各本に関する顧客の姓名及び販売価格及びタイトルを含む最終ｒｅｓｕｌｔｓｅｔ７５Ａに変換する。]
[0027] 図３ＡのＳＱＬ問い合わせ５０に関する望ましい結果は比較的簡単であるが、このシステムは、４つの異なるテーブルにアクセスして顧客エンティティを再組み立てして対応する本タイトルを抽出するように３つの結合演算を処理する必要がある。更に、顧客エンティティの各部分は、異なるテーブル中に常駐し、従って、そのあらゆる注文及びあらゆる品目に非効率なランダムアクセスによって個々にアクセスする必要がある。] 図３Ａ
[0028] より解析的な問い合わせの一例として、図５Ａは、本価格及び品目価格が異なると仮定して州別に本に対する平均現金値引きを取得するＳＱＬ問い合わせ８０を示している。ＳＱＬ問い合わせ８０は、２つの要素を識別するＳＥＬＥＣＴ文８１、すなわち、州コード及び計算現金値引き値を含む。値引き値は、図２の本テーブル３５のリスト属性により記録されたリスト本価格と品目テーブル４０中のＳＡＬＥ属性により中で記録された実際の販売価格との現金差額として確立される。この特定のＳＱＬ問い合わせにおいては、ＦＲＯＭ文８２は、顧客テーブル３６、注文テーブル３７、本テーブル３５、及び州テーブル４１を識別する。ＷＨＥＲＥ文８３は、図３Ａに関して上述したものと同じ方法で適切な関係を確立するために４つの条件を確立する。ＧＲＯＵＰＢＹ文８４は、グループ分けすべき複数の縦列に処理を誘導する。それによって１つの指令で複数の縦列に集約機能を実行することができる。最終ｒｅｓｕｌｔｓｅｔにより、二段組報告書が生成される。一方の縦列は、州名を含み、他方の縦列は、その州の顧客に対する全ての販売に関する平均現金値引きを含む。] 図２ 図３Ａ 図５Ａ
[0029] 図５Ｂは、図５Ａ内のＳＱＬ問い合わせ８０を処理する図３Ｂに示すものに類似した処理を示している。この例においては、ＷＨＥＲＥクローズは、望ましい結果を生成するのに必要である４つの結合を定める。より具体的には、問い合わせ計画９０は、最初に顧客テーブル３６を識別する。第１の結合演算９１では、図５ＡのＷＨＥＲＥクローズ８３の第１の要素に応答してＣｕｓｔｏｍｅｒＩＤ値で顧客テーブル３６及び注文テーブル３７を結合する。第２の結合演算９２では、品目テーブル４０で演算９１によって生成されたデータセットを結合する。第３の結合演算９３では、次に、結合演算９２の結果及び本テーブル３５からの対応する値に基づいてｒｅｓｕｌｔｓｅｔを生成する。最終結合演算９４では、結合演算９３で生成されたｒｅｓｕｌｔｓｅｔ及び州テーブル４１中のデータを結合する。射影演算９５では、州コード、本価格、及び品目価格に関する値を生成する。集約演算９６では、州コードに基づいて、値引き価格の平均値を生成して９７でｒｅｓｕｌｔｓｅｔを生成する。明らかなように、問い合わせ計画９０が構築されると、実行ユニット６２は、問い合わせ計画９０を処理して指定のｒｅｓｕｌｔｓｅｔを生成する。] 図３Ｂ 図５Ａ 図５Ｂ
[0030] 図５ＡのＳＱＬ問い合わせ８０に関する望ましい結果は、３つの縦列だけで作動して比較的簡単なように見えるが、システムは、必要なデータが５つの個々のテーブル中に常駐するので４つの結合演算を処理する必要がある。結合演算の比較的効率的な実施例でさえも、かなりのシステムリソースが必要である可能性がある。テーブルのサイズが増大する時に、結合実施にも問題が発生する。多くの結合演算を処理する必要がある時、処理遅延は、時々許容不能レベルまで増大する。これらの問題にも関わらず、殆どのデータベースは、連続した横列及び属性縦列から成る複数の関連のテーブルとして、関係論理的データモデルに密接に追随する正規化されたテーブル中のデータを格納し続ける。テーブル間の論理関係は、一般的に、データが実際にテーブル中に格納される方法に影響を与えるものではない。データベースシステムは、全てのテーブルに対して関係を確立するために結合を実行し、関連の部分を適合させるために多くのランダムアクセスを必要とするものでなければならない。] 図５Ａ
[0031] 図１及び図２に示すような様々なテーブル中にデータを格納する別の手法では、上述の問題を認識して、テーブルの全ての縦列を縦方向に位置決めすることによってデータベーステーブルを格納することを提案する。それによってＬＡＰアプリケーションを処理する時に検索のためのデータが最適化される。例えば、Ｆｒｅｎｃｈに付与された米国特許第５、７９４、２２９号（１９９８年）では、このような記憶スキーマが開示されている。システムは、図１に示すような従来の論理的関係データベース管理システムテーブルを使用する。従来の横列構造でデータを格納するよりもむしろ、この明細書の図２に示すように、システムは、属性名別に縦列内にデータを格納するだけである。各縦列は、連続してデータページ上に配置されている複数のセル（すなわち、特定の記録の縦列値）を含む。この明細書の図１の関連では、テーブル３７、テーブル４０、及びテーブル４１の各々は、縦列構成で格納される。] 図１ 図２
[0032] 問い合わせに応答して、そのシステムは、関連のデータであるデータの縦列だけを分析して、最適化プログラムを使用してテーブルの結合順序を選択する。システムは、問い合わせに対して主としてこのようなものではない情報から成る横列ベースのデータページは検索しない。検索された縦列ベースのページは、完全にではないにしても、殆どそのような情報を含む。それによってブロックＩ／Ｏ転送分の大型化、従って、ＯＬＡＰ形式の問い合わせの実行の高速化が可能である。各結合演算の実行は、検索及び結合する必要があるのは基本キー及び外部キーの縦列内のデータだけであるので改善することができる。しかし、全ての縦列を結合する必要がある。従って、結合演算の回数は、テーブルの数よりはむしろ属性の数に従って増加する。縦列ベースのシステムでは、良好に機能するのは、射影性が低くかつ選択度が低い問い合わせの場合のみである。別の言い方をすれば、これらのシステムは、射影処理対象の属性が数個のみであり、かつ使用されるデータが横列の殆どからのものである問い合わせに対して適合される。テーブル当たりに多くの属性にアクセスする問い合わせを実行すれば、同じテーブル中の全ての属性に対して多くの結合を実行することが必要になるので非常に非効率になる。従って、どのように簡単なＯＬＴＰ問い合わせでも、その処理は、非常に非効率なものになる。例えば、図１及び図２内の顧客テーブル３６から横列１つだけを検索するには、各々が異なる縦列内に位置する７つの属性値をフェッチすることが必要である。] 図１ 図２
[0033] Ｓａｈ他に付与された米国特許第７、０２４、４１４号（２００６年）では、縦列データの格納も開示されている。このシステムは、テーブルデータを値の縦列に構文解析する。各縦列は、データの連続的ストリップとして記憶装置への転送に向けてデータストリームにフォーマット設定される。単一縦列での蓄積構造及び複数縦列での蓄積構造の両方が開示されている。各縦列は、記憶装置のページサイズに関係なく圧縮データの連続的ストリップとしてデータストリームとして格納される。]
[0034] これらの手法には、多くの横列のいくつかの完全な縦列にアクセスするＯＬＡＰアプリケーションのような使用量パターンに関する問い合わせ処理に向けてストレージを最適化することにより、様々な利点がある。しかし、ＯＬＴＰ問い合わせ処理は非効率的である。そのうえ、単一の完全なエンティティをアセンブルするために、各属性は、ランダムアクセスを手段として別々のバイナリテーブルから検索する必要がある。従って、水平方向記憶スキーマを使用するシステムは、ＯＬＡＰ問い合わせ処理が非効率的であり、一方、垂直方向記憶スキーマを使用するシステムは、ＯＬＴＰ問い合わせ処理が非効率的である。]
[0035] 「キャッシュ性能に関するウィービング関係」（Ａｉｌａｍａｋｉ他、講演論文集、第２７回ＬＤＢ会議、ローマ、２００１年）という名称の論文では、更に別の代替データ記憶スキーマが説明されている。従来のＮ値記憶モデル（ＮＳＭ）においては、データテーブルの横列は、メモリ内のページにわたって広げられている。説明されている「Ｐａｒｔｉｔｉｏｎ Ａｔｔｒｉｂｕｔｅｓ Ａｃｒｏｓｓ（ＰＡＸ）」システムは、各ページ内のデータを垂直パーティションに変換して、キャッシュ利用及び性能を改善する。しかし、横列フォーマット式データは失われ、データのコピーは１つしかない。横列を再形成するためには、横列を含むページ内の垂直パーティション間に「ミニ結合」を実行する必要がある。ミニ結合により、発生するコストは最小のものになるが、その理由は、表示範囲が１ページを超えなくて済むからである。問い合わせ応答では、システムは、各ページを走査して、問い合わせが定める各属性に対して垂直パーティションをフェッチ又は検索する必要がある。条件を満たす横列又は記録が識別及び再構成される。この論文では、この変化による性能強化が説明されているが、あらゆるこのようなシステムは、依然として、ＮＳＭスキーマに従って格納されたデータベースで処理される全ての結合を処理する必要がある。更に、単一の属性を処理するには、依然としてデータテーブルの横列が存在する完全な１組のページをフェッチ及び処理することが必要である。]
[0036] 結合演算のコストを低減する１つの提案されている手法は、ベーステーブルを使用するよりはむしろ以前に定義済みの達成されたビューを使用することによって問い合わせに答えるということである。達成されたビューは、結果が具体的なテーブルとして格納されている予め計算された問い合わせを表し、かつ元のベーステーブルから随時更新することができる。Ｇａｌｉｎｄｏ−Ｌｅｇａｒｉａ他に付与された米国特許第６、５１０、４２２号（２００３年）、Ｌａｒｓｏｎ他に付与された米国特許第６、８５０、９３３号（２００５年）、及びＣｏｌｂｙ他に付与された米国特許第６、１９９、０６３号（２００１年）では、「ビュー利用」に関する問題としても公知である問い合わせに答える達成されたビューの使用への類似の手法が開示されている。すなわち、この手法は、結合されたフォーマットで格納された実体化されたビューを処理することによって特定の問い合わせに答えるための必要な結合演算の回数を低減するということである。Ｌｏｈｍａｎ他に付与された米国特許第６、３５６、８８９号（２００２年）及びＴａｏに付与された米国特許第７、１９１、１６９号（２００７年）では、関連の「ビュー選択」に関する問題に対するいくつかの手法が示されており、実体化すべき１組のビューは、特定の１組の問い合わせを評価するコストが最小にされるように、かつビューが所定のストレージスペース制約条件内にあるように選択される。実体化されたビューに関する手法は、実体化されるこれらの結合演算の数を低減することができる。しかし、これは、その１組のビューを判断、維持、及び格納するという多大なコストになり、それによってその用途が最もリソース消費型である問い合わせだけに限定される。更に、実体化されたビューは、正規化された形態から非常に外れた形態でデータを格納するために、大量のストレージスペースを消費する傾向があり、問題が更に深刻化する。]
[0037] 「亀裂ミラーの事例」（Ｒａｍａｍｕｒｔｈｙ他、講演論文集、第２８回ＶＬＤＢ会議、香港、２００２年）という名称の別の論文では、データがＮＳＭモデル及び「分解ストレージモデル（ＤＳＭ）」に従って格納されるデータベースミラーリング格納スキーマに対して説明されている。２枚のディスクが、ミラーリングされる。１つの手法では、第１のディスクは、ＮＳＭフォーマットで１次データのコピーを格納し、第２のディスクは、ＤＳＭフォーマットに従ってデータの１次コピーを格納する。別の手法では、データの小部分が、２つのコピー間の負荷平衡の改善をもたらすように２つの物理ミラーにわたって格納される。例えば、システムがＮＳＭ及びＤＳＭモデルとして格納されたデータを含む場合、第１のミラーリングディスクは、ＮＳＭモデルからの第１の小部分ＮＳＭ０及びＤＳＭモデルからの第２の小部分ＤＳＭ１を格納することができる。逆に、第２のミラーリングディスクは、ＤＳＭモデルからの第１の小部分ＤＳＭ０及びＮＳＭモデルからの第２の小部分ＮＳＭｌを格納する。このシステムは、各ストレージ小部分の複製コピーを行うが、その主な目標は、他のＲＡＩＤミラーリングスキーマを置換し、かつ異なるスキーマが異なる目的に使用される場合に（ＯＬＡＰ形式のロードに対しては一方のスキーマ、ＯＬＴＰロードに対しては他方のスキーマ）ミラーリングスキーマを組み込むことである。このシステムは、ＮＳＭスキーマに従って格納されたデータベースで処理されると思われる全ての結合も処理する必要がある。]
[0038] 必要とされるものは、複雑なデータベースに対して高収量をもたらし、かつＯＬＴＰ及びＯＬＡＰの問い合わせに対する応答を最適化すると共に、情報要求の複雑化、データモデルの複雑化、及びデータの多量化に対処することができるデータベース管理システムである。更に必要とされるものは、結合の処理を最小にして、順次アクセスを最大に利用し、メモリ、特にディスクメモリ内のランダムアクセス演算を最小にすると同時にデータの２つの完全なコピーを維持するデータベース管理システムである。]
[0039] 米国特許第５、７９４、２２９号
米国特許第７、０２４、４１４号
米国特許第６、５１０、４２２号
米国特許第６、８５０、９３３号
米国特許第６、１９９、０６３号
米国特許第６、３５６、８８９号
米国特許第７、１９１、１６９号]
先行技術

[0040] 「キャッシュ性能に関するウィービング関係」（Ａｉｌａｍａｋｉ他、講演論文集、第２７回ＬＤＢ会議、ローマ、２００１年）
「亀裂ミラーの事例」（Ｒａｍａｍｕｒｔｈｙ他、講演論文集、第２８回ＶＬＤＢ会議、香港、２００２年）]
発明が解決しようとする課題

[0041] 従って、本発明の目的は、高収量をもたらすデータベース管理システム及び方法を提供することである。]
[0042] 本発明の別の目的は、性能及び収量を最適化するために２次元又は記憶スキーマでテーブルデータを格納するデータベース管理システム及び方法を提供することである。]
[0043] 本発明の更に別の目的は、テーブルデータが２つの次元に沿って組織されたデータ構造に格納されるデータベース管理システム及び方法を提供することである。]
[0044] 本発明の更に別の目的は、各々が異なる方法で組織され、それによって特定の使用量パターンに向けて順次アクセスを可能にする２つのデータセットにテーブルデータが格納されるデータベース管理システム及び方法を提供することである。]
[0045] 本発明の更に別の目的は、第１のデータのコピーが修正横列フォーマットで格納され、データの別のコピーが縦列フォーマットで格納されるデータベース管理システム及び方法を提供することである。]
[0046] 本発明の更に別の目的は、従来の問い合わせが、修正横列フォーマットのデータのコピー又は縦列フォーマットのデータのコピーにアクセスすべきか否かを判断する問い合わせ計画に変換されるデータベース管理システム及び方法を提供することである。]
[0047] 本発明の更に別の目的は、データのコピーが結合情報を埋める修正横列フォーマットで格納されるデータベース管理システム及び方法を提供することである。]
課題を解決するための手段

[0048] 本発明を実施するための最良のモード
本発明の第１の態様により、データベース管理システムは、各テーブル群が、１つのルートテーブル及び関連の少なくとも１つの他のテーブルを含み、各論理テーブルが、属性の縦列及びデータの横列を有するように特徴付けられる少なくとも１つのテーブル群を含む論理データベースモデルのデータに関するデータベースストレージを含む。データベースストレージは、第１及び第２のデータストアを含む。第１のデータストアは、第１の次元でデータベース内の複数のメモリ位置内に全てのデータを位置決めし、複数メモリ位置の各々は、ルートテーブルの１つの横列からの全てのデータと、群関連データが１つのルートテーブル横列である他のテーブルからの全ての関連のデータとを含む。この記憶スキーマは、そのルートテーブル横列及び他の関連のテーブル中の関連の横列内の全てのデータへの順次アクセスを可能にする。第２のデータストアは、第２の次元で複数のメモリ位置内にデータベース内の全てのデータを位置決めし、各メモリ位置は、従って、各属性内のデータへの順次アクセスを可能にするためにデータベース内の属性の１つからの全てのデータと全ての対応する値とを含む。]
[0049] 本発明の別の態様により、異なる関係にあるテーブル及びデータ辞書を有する論理データベース内に含まれたデータのデータ構造が生成される。テーブル群は、データ辞書内のデータに基づいて、各テーブル群に対して、ルートテーブル及びそれに関連するテーブルを含む論理データベース内のテーブルから形成される。第１のデータストアユニットは、データベースのデータが第１の次元で格納される全てのテーブル群に対して作成され、複数のメモリ位置の各々は、従って、そのルートテーブル横列及び関連のテーブル横列内の全てのデータへの順次アクセスを可能にするために、ルートテーブルの１つの横列からの全てのデータと、関連のテーブルからの関連のデータとを含む。第２の次元で複数のメモリ位置でデータベース内にデータを格納する第２のデータストアユニットが作成され、各メモリ位置は、従って、各属性メモリ位置内のデータへの順次アクセスを可能にするために、データベース内の属性からの全てのデータと全ての対応する値とを含む。]
[0050] 本発明の更に別の態様により、異なる関係であるルートテーブルと、関連のテーブル及び各テーブル及びデータベース内のそのテーブルのテーブル群を識別するデータ辞書とを有する論理データベースに問い合わせを提供し、テーブルの各々は、縦列内の属性及び横列内のデータを含む。第１のデータストアユニットは、第１の次元でデータベース内にデータを格納し、複数のメモリ位置の各々は、ルートテーブルの１つの横列からの全てのデータと、関連のテーブルからの関連のデータとを含む。第２のデータストアユニットは、第２の次元でデータベース内の複数のメモリ位置に全てのデータを格納し、各メモリ位置は、データベース内の属性の１つからの全てのデータと、全ての対応する値とを含む。問い合わせに応答して、テーブル群及び問い合わせ内のテーブルが識別される。問い合わせを構文解析する段階では、識別された問い合わせテーブルにデータ辞書によって供給されたテーブル群内のテーブルを比較する。データベース及び問い合わせに共通であるテーブル内に含まれる問い合わせ内の属性のリストが抽出される。この情報により、複数の処理オプションのうちの１つの識別が可能である。選択されたオプションでの処理中に、テーブル群に関連するものであった問い合わせの部分を満たす中間ｒｅｓｕｌｔｓｅｔを取得する。中間ｒｅｓｕｌｔｓｅｔを結合することによって最終ｒｅｓｕｌｔｓｅｔを取得する。]
[0051] 添付の特許請求の範囲は、本発明の主題を特に指摘し、かつ明確に主張している。同様の参照番号が同様の部分を指す添付図面に関連して以下の詳細説明を読むと、本発明の様々な目的、利点、及び新しい特徴は、より完全に明らかであろう。]
図面の簡単な説明

[0052] 著者テーブル、本テーブル、顧客テーブル、注文テーブル、品目テーブル、及び州テーブルを含むサンプルデータベースに関する従来技術の一般的な関係図である。
何らかの代表的データを付した図１のテーブルの各々に関する従来技術のデータシート図である。
図１及び図２に表したシステムから関連のデータを検索する特定のＳＱＬ問い合わせを示す図である。
従来技術のシステムがその指令を解釈する問い合わせ計画を示す図である。
図３Ｂの問い合わせ計画の実行中に生成された中間ｒｅｓｕｌｔｓｅｔを集合的に示す図である。
図３Ｂの問い合わせ計画の実行中に生成された最終ｒｅｓｕｌｔｓｅｔを集合的に示す図である。
従来技術のデータベースを実行するシステムユニットの一般的な配置を開示する機能ブロック図である。
図１及び図２内に表したシステムから関連のデータを検索する別の特定のＳＱＬ問い合わせを示す図である。
図５ＡのＳＱＬ問い合わせに関する従来技術の問い合わせ計画を示す図である。
本発明を実行するシステムユニットの一実施形態を開示する機能ブロック図である。
本発明による第１の次元でのデータベースの記憶スキーマの論理的表現を示す図である。
本発明による第２の次元でのデータベースの記憶スキーマの論理的表現を示す図である。
本発明の使用中に生成されるデータ辞書を開示する機能ブロック図である。
図７の記憶スキーマを生成する処理の流れ図である。
図８の記憶スキーマを生成する処理の流れ図である。
図１０Ａ及び図１０Ｂの処理を理解する際に有用な状態図である。
図１０Ａ及び図１０Ｂの処理を理解する際に有用な状態図である。
図１０Ａ及び図１０Ｂの処理を理解する際に有用な状態図である。
図１０Ａ及び図１０Ｂの処理を理解する際に有用な状態図である。
図１０Ａ及び図１０Ｂの処理を理解する際に有用な状態図である。
図２に示すデータを伴った図７内の記憶スキーマの実施例を集合的に開示する図である。
図２に示すデータを伴った図８の記憶スキーマの実施例を開示する図である。
本発明のデータベース管理プログラムにおいて有用である問い合わせ計画を開発及び実行する処理を示す図である。
本発明のデータベース管理プログラムにおいて有用である問い合わせ計画を開発及び実行する処理を示す図である。
本発明のデータベース管理プログラムにおいて有用である問い合わせ計画を開発及び実行する処理を示す図である。
本発明のデータベース管理プログラムにおいて有用である問い合わせ計画を開発及び実行する処理を示す図である。
図３Ａの問い合わせに関して図１４の方法により開発された問い合わせ計画を示す図である。
図３Ａの問い合わせの実行中に生成される様々なｒｅｓｕｌｔｓｅｔを示す図である。
図５Ａの問い合わせに関して図１４の方法により開発される問い合わせ計画を示す図である。
データベース更新に関する流れ図である。
本発明の記憶スキーマを生成する代案を表すＸＭＬ文書の図である。
図１８内の情報に従って組織される図２のデータベースからの実際のデータを表すＸＭＬ文書の図である。] 図１ 図１０Ａ 図１０Ｂ 図１４ 図１８ 図２ 図３Ａ 図３Ｂ 図５Ａ 図７
実施例

[0053] 従来技術のデータベース管理システムの組織及び運用は、本発明及びその利点の理解を容易にするものである。本発明は、まず基本的アーキテクチャ及び記憶スキーマの論理的表現を説明し、次に、特定のデータベースのスキーマ及び問い合わせが処理される処理を説明することによって最も良好に理解することができる。より具体的には、図６〜図１１Ｅは、論理レベルでこのようなシステムを示している。図１２Ａ〜図１３は、図２のデータを組み込む第１及び第２の記憶スキーマの特定の実施例を示している。図１４〜図１６は、システムが図３Ａに示すＳＱＬ問い合わせを問い合わせ計画に変換する処理を示している。データベース内の情報を更新する処理の説明及び代替ＸＭＬ実施例の説明を次に図１７〜図１９で行う。] 図１０Ａ 図１０Ｂ 図１１Ａ 図１１Ｂ 図１１Ｃ 図１１Ｄ 図１１Ｅ 図１２Ａ 図１２Ｂ 図１２Ｃ
[0054] 基本アーキテクチャ
図６は、本発明を組み込むデータベース管理システム１００の一実施例の機能ブロック図である。この基本レベルでは、システム１００は、図４のシステムと類似のものであり、構成要素として、問い合わせ構文解析プログラム１０１、データ辞書１０２、問い合わせプロセッサ１０３、及び変更ログ１０５を含む。明らかなように、これらのシステム構成要素の各々のこの特定的な実施例は、本発明の特定的な実施例により変化する。図４のシステムと異なり、この実施形態では、問い合わせプロセッサ１０３は、問い合わせプロセッサ１０３が開発する問い合わせ計画に従って第１次元データストアユニット１０６、第２次元データストアユニット１０７、又はその両方と対話する。第１及び第２次元データストアユニット１０６及び１０７の各々は、全てのデータを格納するが、異なる記憶スキーマによるものである。その結果として、本発明は、異なる記憶スキーマに従ってであるが、データの２つのコピーを維持することによってデータ冗長度をもたらす。] 図４ 図６
[0055] 第１次元データストアユニット１０６
第１次元データストアユニット１０６は、データが簡単にアクセスされるように「水平」スキーマでデータを格納する。図７に示すように、第１又は「水平」ストレージ容器内のデータは、「クラスター」及び「クラスター横列」を通じて最も粗いとしての「容器」から最も細かいとしての「属性」まで順位付けられるデータの塊により特徴付けられる。これらの用語及び表現の各々は、図１及び図２に示す論理データベースの何らかの部分との一致を有する。「クラスター横列」は、論理テーブル中の１つの横列に対応しており、その横列内の全てのデータを含む。「クラスター」は、関連のクラスター横列を含む。「容器」は、特定のテーブル群に関する全てのクラスターを含む。] 図１ 図２ 図７
[0056] 図１内の論理的表現に適用されるように、図７は、図２内の著者テーブル群３１に対応する「著者クラスター」の第１の容器１１０を示している。第２の容器１１１は、顧客テーブル３６、注文テーブル３７、及び品目テーブル４０を含むテーブル群３２からのデータを含む「顧客クラスター」を格納する。第３の容器１１２は、州テーブル４１を含むテーブル群３３からのデータを含む「州クラスター」を格納する。] 図１ 図２ 図７
[0057] 容器１１０においては、クラスター１１３は、１つ又はそれよりも多くの関連のクラスター横列１１５の組１１４を含む。単一のクラスター横列は、対応するテーブル内の１つの横列に対応する全ての属性及び値を含む。各クラスターにおいては、第１のクラスター横列は、本発明を理解することを目的として、データが他のテーブル内のデータとは独立しているテーブルである「ルートテーブル」から取られる。図１の論理データベースの実施例では、著者テーブル３４、顧客テーブル３６、及び州テーブル４１は、「ルートテーブル」である。] 図１
[0058] 各クラスター横列は、直接アクセス物理データストアのような順次メモリの連続的又は隣接するストレージ位置に格納されている。好ましくはかつ後で明らかになる理由から、各クラスターは、１つの順次読取演算において互いに隣接して位置するいくつかの結果の点数を取得することによって性能を最大に利用するために隣接して格納すべきでもある。状況に基づいて、容器内の隣接するストレージ位置に全てのクラスターを格納することが有益であることになる。しかし、クラスター横列、クラスター、又は容器は、そのように格納する必要はないが、性能の付随する劣化が問題のないことを条件とする。]
[0059] 尚も図７を参照すると、ラスタ横列１１５のような各クラスター横列は、ヘッダ１１６及び本体１１７を含む。各ヘッダは、以下の本体のコンテンツを説明する情報を含む。この特定的な実施例では、各ヘッダは、クラスター「横列識別子（ＲＩＤ）」フィールド１２Ｏ７、「クラスター識別子（ＣＩＤ）」フィールド１２１、「横列形式」フィールド１２２、「属性ビットマップ」フィールド１２３、及び「属性値位置ベクトル」フィールド１２４を含む。] 図７
[0060] 組合せで、すなわち、連結によってなどで、「横列形式」フィールド１２２と共にクラスター「横列識別子（ＲＩＤ）」フィールド１２０は、テーブル群に対して指定の容器内の横列を固有に識別する。「クラスター識別子（ＣＩＤ）」１２１フィールドは、容器内のクラスターを固有に識別する。具体的には、「横列形式」フィールド１２２は、特定のテーブルを識別し、ＲＩＤ値の順序は、そのテーブル内の横列の順序に対応する。一般的に、あらゆるテーブルのＲＩＤ値は、テーブル横列番号である。自動増分単一属性基本キーがテーブル内にある時、ＲＩＤフィールド１２０は、その特定の横列に対してその基本キー値を格納することができる。他の基本キー実施例に対して、ＲＩＤフィールド１２０は、テーブルに追加された疑似縦列として独立したカウンタによって実施することができる。]
[0061] 図１のデータベースに対して、テーブルの各々は、ＲＩＤとして使用されて自動増分基本キーを有すると仮定している。ＣＩＤフィールド１２１は、一般的に、ルートテーブル内の対応する横列に対してＲＩＤフィールド１２０内の値に対応する。従って、クラスター内の第１の横列は、ＲＩＤフィールド１２０及びＣＩＤフィールド１２１において同一値を有する。しかし、あらゆる任意値システムは、ＲＩＤフィールド１２０及びＣＩＤフィールド１２１の両方に対して固有の識別子を供給することができる。] 図１
[0062] 「横列形式」フィールド１２２は、本体１１７のデータソースの性質を定める。すなわち、クラスター横列のデータがテーブルからのものである場合、「横列形式」フィールド１２２は、その目的が対応する特定のテーブルを識別する。他の「横列形式」値は、ＸＭＬ文書化ノード、画像、ＤＮＡセグメント、「小塊」又は他の横列形式を識別することができる。]
[0063] 「属性ビットマップ」フィールド１２３は、クラスター横列内の各属性がデータ又はヌル値を含むか否かを示している。]
[0064] 「属性値位置ベクトル」フィールド１２４内のデータは、属性値Ａ１２５、属性値Ｂ１２６、及び属性値Ｃ１２７のような本体１１７内の属性値を指摘する。クラスター横列内のデータが順番に格納される場合、ベクトルは、アドレス又は基準アドレスからのオフセットによって定めることができる。]
[0065] 第１次元データストア１０６内のデータのこの構造は、大きな利点となっている。具体的には、テーブル群内の全ての記録は、冗長性がない関係で格納され、システムは、特定のテーブル群からデータを取得する結合演算を実行する必要がない。例えば、著者クラスターは、著者の姓名、生年月日、及び連絡先情報があるクラスター横列を含む。ＲＩＤ及びＣＩＤフィールド１２０及び１２１は、対応する著者の基本キーを含む。次のクラスター横列は、ＣＩＤフィールド１２１内に同じ値、ただし、ＲＩＤフィールド１２０内には新しい値を有し、その著者により書かれた１冊の本のｆｋＡｕｔｈｏｒＩＤ値、タイトル、表示価格、刊行日、及び説明を格納する。クラスターは、著者が書いた各々の付加的な本に対して付加的なクラスター横列を含む。各々の付加的なクラスター横列は、ＣＩＤフィールド１２１内に同じ値、ただし、ＲＩＤフィールド１２０内には固有の値を含む。これらのＲＩＤ及びＣＩＤフィールド１２０及び１２１によってこそ、データを図１に示す暗黙の関係に従って格納することができ、かつ著者及び著作に関する全ての情報への容易なアクセスが可能であり、結合演算を実行しなくて済む。] 図１
[0066] 明らかなように、図１のテーブルが「自動増分」形式の基本キーを有する場合、基本キー値もテーブル横列を識別する。その結果として、ＲＩＤ値１２９は、基本キー値に直接に対応しており、すなわち、ＲＩＤ属性１２０は、基本キー属性に相当する。従って、あらゆるクラスター横列１１５の本体１１７内に基本キー値を格納することは必要ではない。基本キー及びＲＩＤ値が同じではなく、例えば、基本キーが電子メールアドレスであり、かつＲＩＤとして使用されない場合、基本キー属性は、本体１１７内に格納される。] 図１
[0067] 第２次元データストアユニット１０７
図８をここで参照すると、第２次元データストアユニット１０７も容器を含む。この特定的な実施例では、これらは、「縦列容器」である。各テーブル−属性組合せに対して、図８の記憶スキーマに従って格納された１つの縦列容器がある。] 図８
[0068] 各縦列容器１３０は、縦列名前フィールド１３２、縦列形式フィールド１３３、データタイプフィールド１３４、及び付加的なインデックスフィールド１３５を有するヘッダ１３１を含む。縦列名前フィールド１３２は、縦列容器を固有に識別する。１つの識別方法は、テーブル名及び属性の連結を含む。例えば、縦列名前フィールド１３２内のＡＵＴＨＯＲ：ＬＡＳＴＮＡＭＥは、同じフィールド名、すなわち、ＣＵＳＴＯＭＥＲ：ＬＡＳＴＮＡＭＥ縦列容器でさえも、別の属性に対して別の縦列と区別する。図６内のデータ辞書１０２は、この情報を含む。] 図６
[0069] 縦列形式フィールド１３３は、そのフィールドに対してデータの構造を表示する。様々な構成の例には、固定長又は可変長フィールド及び固定長コードテーブルがある。図６内のデータ辞書１０２は、この情報を含む。尚も図８を参照すると、データタイプフィールド１３４は、データ辞書情報も使用してデータの性質を識別し、このデータは、そのフィールドのためのストレージの性質を識別する。通常、縦列内の全ての値は、非常に有効な圧縮を可能にする同じデータタイプである。ｓｔｉｎｇ及び倍長整数は、データ形式の例である。付加的なインデックスフィールド１３５は、どのインデックスがその属性に対して存在するかに対して識別し、属性は、インデックスを有していない場合もあれば、１つのインデックス又はいくつかのインデックスを有する場合もある。例えば、日付データフィールドは、日付の範囲を検索するように最適化された１つのインデックス及び特定の日付を見つけるように最適化された別のインデックスを有することができる。] 図６ 図８
[0070] 値の範囲が比較的小さい「性別」の属性などを有する縦列に対して、コードテーブル１３７は、各コード及びその意味を表示する。性別コードテーブルにおいては、例えば、「０」は男性、「１」は女性を表示することができる。属性ストライド位置ベクトル１４０は、通常、可変長データタイプと共に使用される。ベクトル内の各位置は、実際データに対する直接的又は間接的なポインタである。縦列データフィールド１４１は、ヘッダ１３１内で定められるフォーマットに従ってデータを含む。]
[0071] 縦列容器の大きな特徴は、縦列として各属性の１組の値を隣接して格納することによって順次アクセスに向けて最適化することができるという点である。すなわち、列データは、１つの構成で格納することができ、一方、コードデータは、アクセスを改善する別の構成で格納することができる。縦列容器の別の利点は、高圧縮フォーマットで縦列容器内にデータを格納することができる点である。具体的には、縦列形式フィールド１３３は、各々が縦列内のデータの特定のデータ形式、並びに特定の特性を収容するように設計されているデータの異なる構造を定める。例えば、固定長データのまばらな縦列は、どの横列が非ヌル値を含むかに対して識別するためのビットマップ、並びにこれらの横列に対して非ヌル値だけを格納する縦列データフィールド１４１を含む構成を定める縦列形式フィールド１３３を利用することができる。]
[0072] 集合的に、第２次元データストアユニット１０７内の縦列容器は、第１次元データストアユニット１０６内のコピーとは独立したデータベースのコピーを提供する。すなわち、従来技術内のインデックスのような特定の基準に基づいて特定の横列を検索するのではなく、縦列は、効率的に問い合わせのｒｅｓｕｌｔｓｅｔの一部として処理することができるオリジナルテーブルの垂直方向の部分を検索するように設計される。]
[0073] 上述のように、テーブルのＲＩＤフィールドは、そのテーブル内の横列を識別する。縦列構造では、ＲＩＤが常に対応する縦列位置を識別することが必要である。すなわち、顧客−注文−品目群内のルートテーブルのＲＩＤが「２０」である場合、顧客テーブルに関連の各縦列容器内の第２０の横列は、顧客テーブルの第２０の横列内のデータに対応する必要がある。その結果として、ＲＩＤ属性１２０が基本キー属性と同等である場合、基本キーに対して容器を作成することは必要ではない。基本キー及びＲＩＤ値が同じではない場合、基本キー属性は、対応する縦列容器内に格納される。図１のデータベースに対して、第２次元データストアユニット１０７は、２８個の縦列ではなく２２個の縦列を含み、その理由は、図２内の各テーブルは、ＲＩＤとして使用される自動増分基本キーを有するからである。] 図１ 図２
[0074] データベースの形成
上述のように、ＳＱＬは、データベース管理システムのフロントエンドとの良く知られたインタフェースをデータベース設計者に供給する公知の一般的な規格である。データ及び処理問い合わせを格納するバックエンドのあらゆる実施は、データベース設計者に透明でなければならない。本発明は、このような透明性をもたらし、それによってデータベース設計者は、従来のＳＱＬ問い合わせでデータベース管理システムと対話することができ、一方、フロントエンド及びバックエンドは、以下に明らかにするように、より良好な収量及び応答をもたらすために、図７及び図８に示すスキーマに従ってデータベースを定義及びポピュレートする。] 図７ 図８
[0075] 従来技術と同様に、データベース設計者は、テーブル及び属性を定めることによって本発明を組み込むデータベース管理システムと対話する。外部キー及び基本キーは、図１の論理図に示すように、テーブル間の関係を定める。図１内のデータベースのような論理データベースが定義又は更新される時、当業技術で公知の処理では、データ辞書を構築又は更新してテーブル内のデータを更新する。本発明の一実施例により、図９内のデータ辞書１０２のようなデータ辞書は、図４に示すものと同じ基本的メタデータを受信する。著者テーブル３４に関連の辞書メタデータ部分３４ｄに示すようなテーブル及び属性が識別される。] 図１ 図４ 図９
[0076] 本発明では、「テーブル群」を識別する付加的な情報、各テーブル群に対する「ルートテーブル」及びそのテーブル群内のテーブル間の関係も必要である。この情報は、図６の第１及び第２次元データストアユニット１０６及び１０７のそれぞれのスキーマによる図１に示すような論理データベースの物理記憶を容易にするものである。図９、図１０Ａ、図１０Ｂ、及び図１１Ａ〜図１１Ｅは、これらの別種の記憶スキーマに図１の論理テーブルを変形する処理を示している。] 図１ 図１０Ａ 図１０Ｂ 図１１Ａ 図１１Ｂ 図１１Ｃ 図１１Ｄ 図１１Ｅ 図６ 図９
[0077] まず図１０Ａを見ると、処理１５１は、関係モデル内のテーブル、関係、又は属性が作成、削除、又は更新される時にいつでも、すなわち、「更新イベント」時に段階１５２で始まる。サブルーチン１５３は、図１０Ｂに示す段階に従ってデータ辞書１０２内の情報に応答してテーブル群を定める。より詳細にサブルーチン１５３を示す図１０Ｂをここで参照すると、段階１５４で図９内の辞書１０２から関係データモデルを検索した後、段階１５５では、公知の方法及び基本キー及び外部キーに関連の関係を含む図９のデータ辞書内の情報を使用して、図１１Ａに示すような有向グラフを構築する。] 図１０Ａ 図１０Ｂ 図１１Ａ 図９
[0078] このグラフにおいては、「テーブル」は「ノード」と、「リンク」は「有向エッジ」と同等に考えられる。図１１Ａ〜図１１Ｅのノードは、「Ｎ」接尾辞で図１の対応するテーブルに関する参照番号により、有向エッジは、「Ｅ」接尾辞で図１の対応するリンクに関する参照番号により識別される。例えば、図１内の著者テーブル３４は、著者ノード３４Ｎになり、一方、リンク４２は、有向エッジ４２Ｅになる。ノードを識別した後に、有向エッジは、基本キーから外部キーまで延びるように定められる。図１１Ａに示す例においては、有向エッジ４２Ｅは、本テーブル３５がｆｋＡＵＴＨＯＲＩＤ外部キーを含むのでＡＵＴＨＯＲＩＤ属性を有する著者ノード３４Ｎから本ノード３５Ｎまで延びている。] 図１ 図１１Ａ 図１１Ｂ 図１１Ｃ 図１１Ｄ 図１１Ｅ
[0079] 次の段階１５６では、ここで図１１Ｂでの破線として示す有向エッジ４５Ｅのようなあらゆる検索エッジを削除する。ルックアップエッジは、州テーブル４１のようなルックアップテーブルと顧客テーブル３６のような非ルックアップテーブルとの間の高平均濃度により特徴付けられる。ルックアップテーブルは、他のデータとリンクさせることができ、かつ頻繁には変化しないキー属性値を含む参照テーブルである。] 図１１Ｂ
[0080] 次に、段階１５６では、「ルートノード」を定める。「ルートノード」は、あらゆる先行ルックアップエッジが削除された後にそれらに方向付けられたエッジを有していないノードとして定められる。この例においては、段階１５６では、３つのルートノード、すなわち、著者ノード３４Ｎ、顧客ノード３６Ｎ、及び州ノード４１Ｎを定める。]
[0081] 段階１５７では、「重要性」によりルートノードを順序付ける。一般的に、「重要性」は、各テーブル群に関する予想又は測定データ更新アクセス頻度に依存する。図１１Ｂのグラフに示す構造においては、ここで説明する目的上、顧客ノード３６Ｎは、活動が最多であり、著者ノード３４Ｎは、活動が次のレベルであり、州ノード４インチは、活動が最少であると仮定している。段階１６０では、最も重要なルートノードを選択し、段階１６０は、各ルートノード及び他の関連のノード及び有向エッジを終了する段階１６１〜段階１６４を含むループへの入口である。] 図１１Ｂ
[0082] 段階１６１は、全ての関係のあるノードに至る有向エッジに追従してテーブル群定義及び「定義関係」を作成する。「定義関係」は、各群の形成中に追随した有向エッジに対応する。後で明らかなように、各定義関係は、図１０Ａに従って処理した時にテーブル群の構築によって付加的な処理から排除される結合に対応する。] 図１０Ａ
[0083] 第１の反復中に、段階１６１は、顧客ノード３６Ｎで始まり、注文ノード３７Ｎに至る有向エッジ４３Ｅ及び品目ノード４０Ｎに至る有向エッジ４６Ｅに追従する。段階１６１は、次に終了するが、その理由は、品目ノード４０Ｎに関連の唯一の有向エッジ、すなわち、有向エッジ４３Ｅが品目ノード４ＯＮの方向を指しているからである。識別されたノードは、対応するテーブルに対して、グループ分け又は「テーブル群」を定める。この事例では、顧客ノード３６Ｎ、注文ノード３７Ｎ、及び品目ノード４０Ｎは、それぞれ、対応する顧客、注文、及び品目テーブル３６、３７、及び４０を含む。有向エッジ４３Ｅ及び４６Ｅは、２つの定義関係を確立する顧客テーブル群１６５を定める。すなわち、
（１）図９の注文テーブル３７Ｄの特性内に格納されたｆｋＣＵＳＴＯＭＥＲＩＤ＝ＣＵＳＴＯＭＥＲ：ＣＵＳＴＯＭＥＲＩＤ、及び
（２）品目テーブル４ＯＤ内に格納されたｆｋＯＲＤＥＲＩＤ＝ＯＲＥＤＥＲ．ＯＲＤＥＲＩＤ。
このテーブル群に関連のノード及び有向エッジは、次に、図１１Ｃ内の破線により表されるようにグラフから除去される。従って、段階１６２が第１の反復中に完了された後、著者、本、及び州テーブルノード３４Ｎ、３５Ｎ、及び４１Ｎのみがグラフ内に残る。] 図１１Ｃ 図９
[0084] 付加的なルートノードが存在する時、段階１６３は、段階１６４における重要性の順で次のルートノード、すなわち、著者ルートノード３４Ｎを選択するように段階１６４に制御を移す。第２の反復中、段階１６１は、著者ルートノード３４Ｎで始まり、この例においては本ノード３５Ｎに対する有向エッジ４２Ｅに追従する。有向エッジ４３Ｅは、他のいかなるノードも指示しておらず、品目テーブル４ＯＮは、第１の又は顧客群１６５形成中にグラフから除外されてしまっている。従って、この反復が完了する時、有向グラフが、図１１Ｄに示すように表示される。著者ノード３４Ｎ及び本ノード３５Ｎは、ここで、１１Ｄに示すように、ｆｋＡＵＴＨＯＲＩＤ＝ＡＵＴＨＯＲ．ＡＵＴＨＯＲＩＤ定義関係で著者テーブル３４及び本テーブル３５を収容する第２の又は著者群１６６を定める。州ルートノード４１Ｎだけが残っている。] 図１１Ｄ
[0085] 第３の反復中、段階１６４は、州ノード４１Ｎを選択する。州ノード４１Ｎが単独である時、段階１６１では、図１１Ｅに示すように、州ノード４１Ｎによって定められるように州テーブル４１だけを含む第３のテーブル又は州群１６７を作成する。残りの有向エッジがないので、定義関係はない。図１０Ｂの段階１６３は、次に、段階１６５に転じ、段階１６５では、図１１Ｅに示す情報、具体的には、顧客群の定義、著者群、及び州群に示す情報を図１０Ａ内の手順の残りに渡す。] 図１０Ａ 図１０Ｂ 図１１Ｅ
[0086] 図１０Ｂの段階１５７における重要性の判断の順序に変更があった場合、テーブル群定義は変わる。例えば、段階１５７が、著者テーブルが最も重要なルートノードであったように判断することであった場合、図１０Ｂ内のループの第１の反復は、著者ノード３４Ｎ、有向エッジ４２Ｅ、本ノード３５Ｎ、有向エッジ４４Ｅ、及び品目ノード４０Ｎを有する著者群を生成する。対応する定義関係が生成されるであろう。次の反復では、顧客ノード３６Ｎ、有向エッジ４３Ｅ、及び注文ノード２７Ｎ、及び単一の定義関係で顧客テーブル群を定める。ルートノードの順序の判断は、あまり重要なものではない。重要な順序が最適でないことが判明した場合、この順序は、蓄積された統計情報に応答して手動で又は自動的に調節することができる。] 図１０Ｂ
[0087] 次に、制御は、図１０Ａに戻り、この時点で、一連のネスト化ループを形成する段階１７０〜段階１７４では、系統的にサブルーチン１５３によって得られた情報を処理する。複数の反復中に、ネスト化ループは、図７及び図８のデータ構造を実行する図６の第１及び第２次元データストアユニット１０６及び１０７の各々に対して容器を生成する。図１の特定の例に対して、容器は、ユニット１０６内では各テーブル群に対して、ユニット１０７内では、各テーブル及びそのテーブル内の属性に対して形成される。具体的には、段階１７０では、それ以上テーブル群を処理する必要があるか否かを判断する。最初に、全てのテーブル群を処理していなければならず、従って、１つが選択される。その順序は、重要ではない。] 図１ 図１０Ａ 図６ 図７ 図８
[0088] 段階１７１では、「長さ」のような属性及び定義済みの関係で格納された情報を含む対応するメタデータを使用してその群に対して新しい水平容器データ構造を作成する。すなわち、段階１７１では、図７に示す著者容器１１０、顧客容器１１１、及び州容器１１２のデータ構造のようなデータ構造を生成する。] 図７
[0089] 次に、システムは、テーブル及び属性を処理する。段階１７２では、処理を必要とするテーブルが群内にそれ以上あるか否かを判断する。ない場合、制御は、段階１７０に戻る。テーブルがある場合、段階１７３では、処理する必要がある属性がそのタブレット以内にそれ以上あるか否かを判断する。ない場合、制御は、段階１７２に戻る。ある場合、段階１７４では、そのテーブル内の各属性に対して新しい縦列容器データ構造を作成し、各容器は、図８に示すようなデータ構造を有する。上述のように、図１に示す論理データベースに対して、システムは、著者テーブル３４に対して４つの縦列容器を、本テーブル及び顧客テーブル３５及び３６の各々に対しては５つの縦列容器を、注文テーブル３７及び品目テーブル４０に対して３つの縦列容器を、州テーブル４１に対しては２つの縦列容器を作成する。] 図１ 図８
[0090] 図１０Ａ及び図１０Ｂの以上の説明は、特に、データベースの作成に関するものである。当業者に明らかなように、処理１５１は、全体的又は部分的に関わらず、あらゆる関係の変化、又はテーブルの追加、削除又は修正、及び属性の追加、削除又は修正を処理に適応させることができる。] 図１０Ａ 図１０Ｂ
[0091] ここで、本発明により図１及び図２のデータベースに対して図６の第１次元データストア１０６のための容器内での記憶スキーマの特定の実行を説明することが役立つと考えられる。図１２は、格納済み容器１１０、１１１、及び１１２が、上述のように、連続的反復の後に図１０Ａの段階１７１によりを生成されたデータストアユニット１０６の全体的な論理構成を示している。著者容器１１０は、各著者に対して１つのクラスターを含む。図２のデータに関する特定の実行においては、クラスター１８０は、著者「Ｓａｍ Ｊｏｎｅｓ」に関する情報を格納し、クラスター１８１は、「Ｂａｒｂａｒａ Ｓｍｉｔｈ」に関する情報を格納する。] 図１ 図１０Ａ 図１２ 図２ 図６
[0092] 各クラスターは、１つ又はそれよりも多くのクラスター横列を有する。この例においては、各クラスターは、著者クラスター横列及び２つの本クラスター横列を含む。特定の用途においては、かつ図１１Ｅのグラフに従って著者クラスター１８０は、著者クラスター横列１８２、本クラスター横列１８３、及び第２の本クラスター横列１８４を含み、データベース内には、その特定の著者により各々の本に対して１つの本クラスター横列がある。「Ｂａｒｂａｒａ Ｓｍｉｔｈ」に関するクラスター１８１も、著者クラスター横列１８５及び２つの本クラスター横列１８６及び１８７を含む。] 図１１Ｅ
[0093] 図１２Ａ及び図１２Ｂは、両方のクラスターの詳細を示すが、以下の説明は、図１２Ａのクラスター１８０が中心となっている。著者クラスター横列１８２は、全て、図７に示すように、ＲＩＤフィールド、ＣＩＤフィールド、クラスター横列形式、属性ビットマップ、クラスター横列に存在すると記載された属性に対するポインタを含む。各クラスター横列の上部のテキストは、説明を目的としたものに過ぎない。下部のデータだけが格納される。このクラスター横列１８２においては、ＲＩＤ値及びＣＩＤ値は、同じであり、図２のルート著者テーブル３４内の１つの横列に対応するルートクラスター横列を指定するものである。この著者に対して、クラスター横列は、縦列容器内の対応する縦列の第２００の横列内にある。この例においては、全ての属性は、値を有するので、全ての属性ビットマップは、「１」という値を有する。ポインタ（ＰＴＲ）フィールドは、直接、間接に関わらず、属性ビットマップが識別する４つの属性の各々に関する値を示している。上述のように、基本キー属性は、クラスター横列の本体内には存在しないが、その理由は、ＲＩＤ値として使用され、かつクラスター横列形式フィールドと共に、固有のテーブル及び横列を定めるからである。] 図１２Ａ 図１２Ｂ 図２ 図７
[0094] クラスター横列１８２及び１８３の各々は、本テーブル３５又は著者テーブル群１６５内の本の固有の値に対応する異なるＲＩＤ値を有する。ＣＩＤフィールドは、著者クラスター横列１８２内のＣＩＤフィールドの場合と同じ値を含む。それによって本は、著者に関連のものとして確立される。ＰＴＲフィールドは、属性ビットマップが識別する５つの属性の各々に関する値を示している。]
[0095] 図１２Ｂ内のクラスター１８１に関するクラスター横列１８５、１８６、及び１８７の各々は、図１２Ａの対応するクラスター横列１８２、１８３、及び１８４と類似の構造を有する。本発明の別の特徴を強調表示する１つの相違点がある。図２内のデータによれば、「Ａｄａｍ Ａｐｐｌｅ」は、連絡先情報を示しており、「Ｂａｒｂａｒａ Ｓｍｉｔｈ」は、示していない。従来技術であれぱ、「Ｂａｒｂａｒａ Ｓｍｉｔｈ」の連絡先属性は、「ヌルフィールド」内に格納される。図示のように、クラスター１８２内の属性ビットマップ１９０内の「連絡先」エントリは、「１」を含み、「連絡先」属性１９１は、データを含む。クラスター横列１８５においては、属性ビットマップ内の連絡先エントリ１９２は、「０」を含み、メモリ空間は、１９３で破線により表されるような連絡先属性に対しては割り当てられていない。この特徴により、連絡先属性１９３に対してヌル値を格納及び処理しなくて済む。明らかなように、この特徴は、ストレージスペースの低減に寄与し、かつＳＱＬ問い合わせのデータ設計者の構造を簡素化するものである。] 図１２Ａ 図１２Ｂ 図２
[0096] 図１２Ｃ、図１２Ｄ、及び図１２Ｅは、図１及び図２の顧客テーブル、注文テーブル、及び品目テーブル３６、３７、及び４０からのデータを含む容器１１１内の顧客テーブル群１６５に関するストレージ実施を示している。図１２に示すように、顧客容器１１１は、各顧客に対して１つのクラスターを含む。図２のデータに関する特定の実施においては、クラスター１９４は、「Ａｄａｍ Ａｐｐｌｅ」に関する情報を格納し、クラスター１９５は、「Ｂｏｎｎｉｅ Ｂｉｒｄ」に関する情報を格納する。] 図１ 図１２ 図１２Ｃ 図１２Ｄ 図１２Ｅ 図２
[0097] 代表例としての図１２Ｃ及び図１２Ｄを見ると、クラスター１９４は、顧客クラスター横列２００及び「Ａｄａｍ Ａｐｐｌｅ」による２つの注文に対応する２つの注文クラスター横列２０１及び２０２を含む。注文クラスターの各々の次には、品目クラスター横列がある。具体的には、注文クラスター横列２０１の次には２つの品目クラスター横列２０３及び２０４があり、一方、注文クラスター横列２０２の次には、単一の品目クラスター横列２０５がある。「Ｂｏｎｎｉｅ Ｂｉｒｄ」に関するクラスター１９５のストレージは、この構成に追従する。「Ｂｏｎｎｉｅ Ｂｉｒｄ」が１冊の本に対して１つの注文を行っているので、クラスター１９５は、顧客クラスター横列２０６、順序クラスター２０７、及び品目クラスター２０８を含む。] 図１２Ｃ 図１２Ｄ
[0098] 容器１６７内の州テーブル群は、テーブルが１つのみであるので、ストレージは、図７に示すように表示され、容器１６７は、各州に対して「１」の州クラスターを格納し、２つの州クラスター２１０及び２１１が示されている。図１１Ｅが含む州テーブル群内のノードは１つのみであるので、各クラスターは、単一のクラスター横列によって形成される。] 図１１Ｅ 図７
[0099] 上述のように、図６の第２次元データストア１０７は、図１の論理データベースから導出された各テーブル−属性組合せに対して１つの容器を格納する。ＲＩＤフィールドが基本キー値を含む場合、基本キー属性に対して縦列を格納する必要はない。] 図１ 図６
[0100] 各容器は、ヘッダ及びデータを格納する。以下で説明する内容においては、「ヘッダ」及び「データ」は、ヘッダフィールドのよう特定のフィールド、又は状況的に認められる時にはそのフィールド内に含まれる情報を定めるために使用される。図１３は、図８のような全体的な構造を有する図１及び図２のデータベースに関する縦列容器の３つのインスタンス生成を示している。尚も図１３を参照すると、容器の各々は、「ヘッダ」及び「データ」区画を含む。すなわち、容器２２０は、「ヘッダ」２２３及び「データ」２２４を含み、容器２２１は、図８に示すベクトル１４０のような属性ストライド位置ベクトル２２６を有するヘッダ２２５及びデータ２２７を含み、容器２２２は、コードテーブル２３１を有するヘッダ２３０及びデータ２３２を含む。] 図１ 図１３ 図２ 図８
[0101] 各縦列容器内のヘッダは、データの特性に関する固有の識別及び情報を含む。これらのインスタンス生成においては、固有の識別は、テーブル名及びそのテーブル内の属性の名前の連結を含む。例えば、縦列容器２２０の識別は、ＢＯＯＫ＿ＬＩＳＴである。従って、縦列２２０は、本テーブル３５内の全ての本に関する表示価格を含む。容器２２１及び２２２の各々は、顧客テーブル３６内のＬａｓｔＮａｍｅ及び性属性を表し、かつＣＵＳＴ＿ＬＡＳＴＮＡＭＥ及びＣＵＳＴ−性により固有に識別される。]
[0102] データ特性を定めている各ヘッダの部分では、データ設計者が行う初期選択に基づいて図９内のデータ辞書から情報を使用する。容器２２０は、固定長の倍長整数データを定め、容器２２１は、可変長列データを定め、容器２２２は、列データを有する固定長のコードテーブルを定める。] 図９
[0103] この実施例では、テーブルの基本キーは、カウンタ値が連続してそのテーブル内の各横列を識別するように、自動増分カウンタであると仮定する。例えば、容器２２０のデータ２２４内の値「１７．００」は、そのテーブル内の横列番号「１」を指す。この実施形態では、そのテーブルには、特定の横列を識別する各テーブルに関連のカウンタが本質的に存在する。]
[0104] いずれの実施でも、あらゆる縦列容器内のデータの順序が同じテーブルの他の縦列容器と同じ順番であることが必要であることは、必要不可欠なものである。同じテーブルの属性に関する縦列容器内の各横列においては、その横列内のデータのポインタとして基本キーを使用する。この形式の識別の使用は、容器内のデータとは独立したものである。例えば、容器２２１は、「Ｊｏｎｅｓ」のような共通の名前を有する複数の横列を含むことができる。名前の各例は、固有の識別子、すなわち、顧客テーブル３６の基本キー値を有する。]
[0105] 問い合わせ処理
問い合わせに応答する問い合わせプロセッサ１０３、図６内の第１及び第２のデータストアユニット１０６及び１０７、及び図９内のデータ辞書１０２の間の対話に対して、問い合わせ計画を構築する図１４の繰返しルーチン２４０を参照してここで説明する。問い合わせプロセッサ１０３は、最初に、段階２４１で問い合わせに関わる全てのテーブル群を識別する。次に、段階及びサブルーチン２４２〜２４５を含む繰返し処理では、２４２で識別済みのテーブル群を選択する。問い合わせ構文解析プログラム１０１は、最初に問い合わせ及びデータベースから情報を使用して、そのテーブル群内のどのテーブルが分析に関連するかを識別する。次に、最適化する段階では、サブルーチン２４４において、選択されたテーブル群に関してデータベースのどれだけがアクセスされ、そのテーブル群に対して問い合わせ基準を満たす全てのデータを有する中間結果組を取得するよう処理されるかを判断する。段階２４５で全ての関連のテーブル群が分析されたように判断した時、結合／処理段階２４６では個々の中間結果組を結合して、問い合わせが要請した情報を含む正式な結果組にする。] 図１４ 図６ 図９
[0106] 図１４Ｂは、構文解析するステージ１０１で関連のテーブルを判断する段階を開示する。] 図１４Ｂ
[0107] 具体的には、段階２５０では、ルートノードを使用し、従って、顧客ノード３６Ｎ、注文ノード３７Ｎ及び品目ノード４０Ｎ、及び対応する有向エッジ４３Ｅ及び４６Ｅを含む図１１Ｃ内の顧客テーブル群１６５のグラフのように、グラフをもたらすためにデータ辞書から関係エッジを定めて、選択されたテーブル群の第１のグラフを作成する。] 図１１Ｃ
[0108] 段階２５１では、下表１及び下表２に示すような問い合わせ内の情報に基づいて対応する第２のグラフを作成する。顧客テーブル群の場合、段階２５１では、顧客テーブルＴｌ、注文テーブルＴ２、及び品目テーブルＴ３、及び問い合わせ内の結合述語５４及び５５を使用する。]
[0109] 更に詳しく説明すると、図３Ａの問い合わせは、テーブル「Ｔｉ」及び属性「Ａｊ」を含み、「ｉ」及び「ｊ」は、Ｔｉ及びＡｊがテーブル及び各テーブル内の属性を示すような数を示すと仮定して、段階２５１では、以下のように問い合わせを形成するテーブル及び属性を識別することができる。] 図３Ａ
[0110] （表１）]
[0111] 属性Ａ１〜Ａ４は、図３Ａの「Ｓｅｌｅｃｔ」文５１から取られ、テーブルＴ１〜Ｔ４は、「Ｆｒｏｍ」文５２から取られ、属性Ａ５〜Ａ１０は、述語を定める「Ｗｈｅｒｅ」文５３の線５４〜５７から取られる。「Ｗｈｅｒｅ」文内の５３線５７は、「選択度」述語である。線５４〜５６の結合述語は、以下のように表される。] 図３Ａ
[0112] （表２）]
[0113] 段階２５２は、次に、グラフを分析してどのテーブル及び関係が両方のグラフに共通であるかを判断する。別の言い方をすれば、段階２５２は、問い合わせに関わり、かつデータ辞書１０２内の定義関係で結合されるテーブル群内のテーブルを識別する。この例における顧客テーブル群１６５の分析により、検索対象である顧客テーブル群内のテーブルのうちの３つの全てが識別される。テーブル群内のこの組のテーブルのデータは予め結合されたクラスターを有する対応するクラスター容器から検索することができるので、顧客テーブル群内の個々のテーブルに関して関係を定めるテーブル中群結合演算は不要である。一部のテーブルは重なり、又はテーブル群内の別のテーブルに接続しない可能性があり、その場合、接続したテーブルは、独立して処理されるサブ群を成す。]
[0114] 図１４Ｂでは、段階２５３は、問い合わせによりアクセスされ、重なり合ったテーブル（ＯＴ）のうちの１つの中に含まれ、かつ容器内の特定のクラスターに対してＲＩＤの役割もする基本キーではない全ての属性（ＯＴ＿ＡＴＴ）のリストを抽出する。概念的には、属性の抽出されたリストは、第２次元データストアユニット１０７を使用してこのテーブル群に対して結果組を生成するためにアクセスする必要がある１組の縦列を表している。顧客テーブル群の場合、列挙された属性（ＯＴ＿ＡＴＴ）の数により、顧客テーブル３６、注文テーブル３７、及び品目テーブル４０内の全てのアクセスされる属性が識別される。表１を参照すると、リストは、属性Ａ１〜Ａ４、並びにＡ６、Ａ８及びＡ１０の各々を含む。属性Ａ５及びＡ７は、各々がＲＩＤとして使用される基本キーであるので含まれない。属性Ａ９は、別のテーブル群に属するので含まれない。] 図１４Ｂ
[0115] テーブル群に関する処理方法の選択は、段階２５３の働きが選択度及びアクセスされることになるテーブル群内のデータの百分率の推定で完了した後に始まる。図１４Ｂをここで参照すると、段階２５４で、システムは、段階２５３の抽出されたリスト内の属性を含む非結合述語に対して選択度を推定する。１つの手法では、システムは、非結合述語内の属性又は属性群に対して指定された縦列容器又は容器群を検証する。次に、縦列容器内の横列の総数に合わせて選択されると予測される横列数により判断される百分率を推定する。複数の非結合述語がある時、結果を統計学的に結合して総合選択度推定値を取得する。簡単な手法は、単に、１つのテーブル内のフィルタリング後の属性の各々に対して推定選択度を増大させることである。選択度は、高選択度の場合の「０」から低選択度の場合の「１」まで変動する可能性があり、これは、属性に関連の全ての横列を含むことになることを示している。全体的な選択度は、アクセスされるルートテーブル横列又はクラスターの数を示す傾向がある。換言すると、全体的な選択度値は、現在のテーブル群内でアクセスする必要があるクラスターの総数の百分率を示している。] 図１４Ｂ
[0116] 総合選択度が段階２５４で判断された時、段階２５５では、総合情報百分率（ＰＩＲ）を計算する。ＰＩＲ値は、アクセスする必要があるテーブル群の容器内のデータの総量から百分率を示す傾向がある。それは、以下のように計算される。
ＰＩＲ．（ＥＳＴＩＭＡＴＥＤ＿ＳＥＬＥＣＴＩＶＩＴＹ）*ＯＴ＿ＡＴＴ．ＴＯＴＡＬ＿ＡＴＴＲＩＢＵＴＥＳ＿ＩＮ＿ＯＴ]
[0117] 図３Ａの問い合わせの場合にかつ上表Ｉを参照すると、ＯＴ ＡＴＴ＝７及びＯＴ＝２２である。選択度がない場合、ＰＩＲ＝０．５８である。選択度が増加する時に、ＰＩＲは減少し、図３Ａの場合のようにゼロに近づき、１つの顧客のみが、非結合述語５７により選択される。] 図３Ａ
[0118] 段階２５８は、ＰＩＲ値を閾値と比較する。閾値は、当業技術で公知のいくつかのファクタ及び処理に従って設定される。考慮すべきファクタの例には、テーブル群サイズ、ディスク待ち時間及び帯域幅、メモリ待ち時間及び帯域幅がある。結合演算コストの推定は、処理の一例である。一般的に、これらの処理は、統計学的に一定期間にわたってシステム演算を分析し、かつ定期的に段階２５３〜２５５の分析を実行する。例えば、閾値は、１つのランダム演算中に順番に読み取ることができるテーブル群からのデータの百分率として計算することができる。帯域幅が１つのランダム読取を実行するために掛かる同じ時間に選択されたテーブル群に対して容器内のクラスターの読取値３０％を可能にする場合、テーブル群の閾値は、７０％に設定することができる。この値は、次に、利用可能な統計値に基づいて手動で及び／又は自動的に調節することができる。]
[0119] 最適化する段階２４４では、いくつかのオプションのうちの１つを選択する初期基準として抽出されたリスト内の属性の数及びＰＩＲ値を使用する。この実施形態では、５つのオプションがある。単一の属性のみが抽出されたリスト内にある場合、段階２５６は、第１のオプションを処理する段階２５７に転送する。属性が１つのみであるので、単一の垂直容器のみを走査する必要がある。段階２５７では、次に、そのテーブル群に対して中間結果組を生成する。１つよりも多い属性がある場合、段階２５８では、ＰＩＲ値を検証する。ＰＩＲ値が予め設定された閾値よりも大きい場合、段階２５８は、第２のオプションを表す段階２５９に制御を転送する。具体的には、この判断は、図７の対応する容器１１０内のクラスターの高い百分率が、ｒｅｓｕｌｔｓｅｔを取得するために走査する必要があり、かつテーブル群容器内の全てのクラスターの走査により最良の結果が得られることを示している。段階２５９では、容器内のクラスター横列を順番に走査することによってそのタスクを実行して、そのテーブル群内の情報に基づいてｒｅｓｕｌｔｓｅｔを取得する。段階２５９の出力は、従って、特定の問い合わせのその部分を満たすテーブル群に関するデータの横列を有する中間ｒｅｓｕｌｔｓｅｔである。] 図７
[0120] 選択度が増加するか又は属性ＯＴ＿ＡＴＴ／ＯＴの比率が減少する時に、ＰＩＲ値は、閾値よりも小さい。段階２５８は、段階２６０に転じ、段階２６０では、従って、対応する垂直縦列をフィルタリングするために問い合わせ内のあらゆる関連の非結合述語を実行する。各々の関連テーブル内でアクセスする必要がある横列を表すビットマップとして中間ｒｅｓｕｌｔｓｅｔを戻す。]
[0121] 段階２６１では、段階２６０の結果を分析して、いくつかの代案のコストを統計学的に分析し、このような３つの代案は、図１４Ｂに示されており、第３〜第５のオプションを表している。本発明の関連での「コスト」は、演算を完了するのに必要とされる時間の推定値である。メモリ内のクラスター又は垂直縦列の順次走査の推定値は、そのデータを読み取る時間にある。クラスター又は垂直縦列がディスク上だけにある場合、時間は、第１の位置に到達する時間プラスその属性に対して順次値の各々を処理する時間に依存する。オプション４に関連するようなランダム演算に対しては、属性への毎回のアクセスの時間を含むことになる。] 図１４Ｂ
[0122] 具体的には、オプション３では、テーブル群に対して水平容器１１０内の全てのデータを順番に走査するコストを計算する。オプション４では、段階２５３で得られた属性の抽出されたリストに対応する各垂直縦列容器内のデータを順番に走査するコストを計算して、これらの縦列に結合する。オプション５では、水平容器１１０からのクラスターのランダム取り出しのコストを計算する。]
[0123] 段階２６２では、３つのオプションを含む段階２６１によって得られた全てのオプションのコストが最低であるオプションを選択する。他のオプションを考慮することができる。]
[0124] この実施形態では、段階２６３は、直ちに中間ｒｅｓｕｌｔｓｅｔを定めることを始める。これは、特に、多重処理システムにおいて有利であり、その理由は、段階２６２からの情報は、演算を直ちに始めることができるからであり、複数のテーブル群がある場合、段階２６３の機能は、平行処理のための異なる処理システムに関するものとすることができる。他の代案を用いることができる。例えば、段階２６２からのデータは、問い合わせ計画内の段階に対応する。これらの段階は、バッファに入れることができる。次に、システムは、問い合わせ計画で開示しているように、各テーブル群に対して順番に情報を処理することができる。]
[0125] それによって図１４内の段階２４２で選択されるテーブル群の分析が終了する。図３Ａの特定の問い合わせにおいては、図１４内の段階２４５は、第２のテーブル群、例えば、著者テーブル３４、本テーブル３５、及びリンク４２を含む著者テーブル群を選択する段階２４２に制御を戻す。図１４Ａの段階２５２では、これらのグラフに重ね合わせる時に本テーブルのみが残り、このような唯一の属性は、ＴＩＴＬＥ属性である。このテーブル群に対しては非結合述語がないので、段階２５４ではフィルタリングを行わない。従って、２５５において計算されたＰＩＲ値は、予め設定された閾値を下回り、ＯＴ＿ＡＴＴ＝１であり、従って、制御は、段階２５８から段階２６０まで再び移る。] 図１４ 図１４Ａ 図３Ａ
[0126] 垂直縦列に関連の非結合述語がないので、その結果により、本テーブル内の各タイトルが識別される。この場合、段階２６１での分析により、オプション３が選択され、Ｂｏｏｋ：Ｔｉｔｌｅ垂直縦列が走査される。実行された状態で、この走査からのｒｅｓｕｌｔｓｅｔは、全ての本タイトルを含み、従って、このｒｅｓｕｌｔｓｅｔにより全ての本の中間ｒｅｓｕｌｔｓｅｔが生成される。]
[0127] 全てのテーブル群が処理された時、段階２４５は、サブルーチン２４６に制御を移し、サブルーチン２４６では、結合／処理手順２４６により、最終ｒｅｓｕｌｔｓｅｔが得られ、収集データを分析して問い合わせ計画を完了する。]
[0128] 図１４Ｃを参照すると、段階２６４では、１つよりも多いｒｅｓｕｌｔｓｅｔが図１４Ｂの手順によって生成された組内に残されているか否かに判断する。２つ又はそれよりも多いｒｅｓｕｌｔｓｅｔが残されている場合、段階２６４は、段階２６５に移り、段階２６５では、最小の残りのｒｅｓｕｌｔｓｅｔ、すなわち、横列数が最少であるｒｅｓｕｌｔｓｅｔを選択する。段階２６７では、結合述語を有する対象である次のより小さいｒｅｓｕｌｔｓｅｔとの結合を実行する。組み合わされたｒｅｓｕｌｔｓｅｔは、結合されたｒｅｓｕｌｔｓｅｔと入れ替わる。ｒｅｓｕｌｔｓｅｔが１つだけが残っている時、最終処理演算、例えば、選別、集約を実行しては問い合わせを完了する。] 図１４Ｂ 図１４Ｃ
[0129] 特に図３Ａの問い合わせに関しては、最小ｒｅｓｕｌｔｓｅｔは、顧客テーブル群に関するｒｅｓｕｌｔｓｅｔであり、その理由は、問い合わせが、特定の顧客を識別するからである。この情報を処理することは、図１５Ａの段階２７１及び２７２に同等である。中間ｒｅｓｕｌｔｓｅｔにより、各品目に関する１つの横列、及びｆｋＢＯＯＫＩＤ外部キーを含む顧客テーブル３６、注文テーブル３７、及び品目テーブル４０からの全ての属性に関する縦列を有するｒｅｓｕｌｔｓｅｔ２７２Ａによって示すように、特定の顧客、その顧客が行った各注文、及び各注文に対して購入された品目又は品目群が識別される。ｒｅｓｕｌｔｓｅｔ２７２Ａを段階２７３からの本タイトルｒｅｓｕｌｔｓｅｔ２７３Ａで結合することから生じる次のｒｅｓｕｌｔｓｅｔは、ｒｅｓｕｌｔｓｅｔ２７４Ａを生成する結合演算２７４である。段階２７５では、ＳＥＬＥＣＴクローズ内の全ての属性を含む射影２７５Ａを生成する。結果は、段階２７６により表示される。] 図１５Ａ 図３Ａ
[0130] このシステムの利点は、図３Ｂ及び図１５Ａの問い合わせ計画を比較することによって認識することができる。本発明に対して、初期段階２７１には、顧客容器内の全てのクラスターを含む。オプション４による２７２段階でのＣｕｓｔｏｍｅｒＩＤ＝２０を有する値の選択により、第１の中間ｒｅｓｕｌｔｓｅｔ２７２Ａが得られる。結合演算は発生しておらず、一方、図３Ｂでは、類似のｒｅｓｕｌｔｓｅｔを生成するためには２つの結合が必要である。結合２７４を図３Ｂの段階７４での対応する結合の場合と同様に実行して、本テーブル全体ではなく必要なＴＩＴＬＥ縦列のみが処理される点を除き、第２の中間ｒｅｓｕｌｔｓｅｔ２７４Ａを生成する。上述のように、本テーブルのＲＩＤ値は、基本キーＢＯＯＫＩＤに相当する。従って、縦列容器内のＢｏｏｋ：Ｔｉｔｌｅの順序は、ＲＩＤ値に対応するので、２縦列テーブルと論理的に考えることができ、第１の縦列は、ＢＯＯＫＩＤ属性であり、第２の縦列はＴＩＴＬＥ属性である。第１の中間ｒｅｓｕｌｔｓｅｔ２７２Ａ内の各横列内のｆｋＢＯＯＫＩＤ値は、本テーブル内の基本キーに対応するので、システムは、本テーブル内のＢＯＯＫＩＤ基本キーを有する各品目内のｆｋＢＯＯＫＩＤフィールド間のリンク機構に基づいて従来の結合を実行する。より具体的には、結合演算２７４では、第１の中間ｒｅｓｕｌｔｓｅｔ２７２Ａ内の各横列からｆｋＢＯＯＫＩＤを取得すると、対応するＴＩＴＬＥが得られるようにそのＢＯＯＫＩＤ値に関する本データ２７３Ａにアクセスする。] 図１５Ａ 図３Ｂ
[0131] しかし、段階２７４での結合演算では、図３Ｂの段階７４の場合と同様に、５つの他の属性の全てを含む本テーブル全体３５からＴＩＴＬＥ属性を抽出する必要があるのではなく、本テーブルからＴＩＴＬＥ属性縦列２７３のみを処理する。すなわち、データ量の１／５のみが処理され、従って、データ転送時間、並びにランダムアクセスを低減することによってコストが低減され、従って、演算高速化が可能である。図３Ｃ及び図１５Ｂを比較した後に明らかなように、本発明は、ｒｅｓｕｌｔｓｅｔ数を５から３に低減しており、その理由は、図３Ｂにおいて問い合わせ計画により必要とされる３つの結合は、図１５Ａの問い合わせ計画においては、１つの結合演算に低減されるからである。] 図１５Ａ 図１５Ｂ 図３Ｂ 図３Ｃ
[0132] 図５Ａの問い合わせは、図１４に関する類似の経路に追従する。段階２４１では、問い合わせに関連する３つのテーブル群の全て、すなわち、顧客−注文−品目のテーブル群、著者−本のテーブル群、及び州テーブル群を識別する。段階２４２は、最初に顧客−群−品目テーブル群を選択すると仮定すると、段階２５０及び２５１のグラフは、同一のものになり、従って、重ね合わせるべき顧客テーブル、注文テーブル、及び品目テーブルが識別される。図１４Ｂを参照すると、問い合わせ内で選択された属性は、顧客ＩＤ及びｆｋＳＴＡＴＥＩＤフィールドである。非結合述語がないので、フィルタリングは行われない。従って、第１の反復においては、段階２５３は、７つの属性、すなわち、以下のリストを抽出する。
（１）ｔｂｌｌＴＥＭ．ＳＡＬＥ、
（２）ｔｂｌＣＵＳＴＯＭＥＲ．ＣＵＳＴＯＭＥＲＩＤ、
（３）ｔｂｌＯＲＤＥＲ．ｆｋＣＵＳＴＯＭＥＲＩＤ
（４）ｔｂｌｌＴＥＭ．ｆｋＢＯＯＫＩＤ
（５）ｔｂｌＯＲＤＥＲ．ＯＲＤＥＲＩＤ
（６）ｔｂｌｌＴＥＭ．ｆｋＯＲＤＥＲＩＤ
（７）ｔｂｌＣＵＳＴＯＭＥＲ．ｆｋＳＴＡＴＥＩｄ] 図１４ 図１４Ｂ 図５Ａ
[0133] 従って、（２）及び（５）は、ＲＩＤ値として使用される属性であり、テーブル群内には、ＲＩＤとして使用されない属性のうちの５つがあり、従って、ＰＩＲ＝１*５／１１であり、ＰＩＲ値は、一般的に閾値よりも大きいことになる。段階２５８は、段階２５９に転じ、段階２５９では、顧客水平容器の順次走査を使用して顧客−注文−品目のテーブル群ｒｅｓｕｌｔｓｅｔを生成する第２のオプションを選択する。]
[0134] 次の反復においては、段階２４２は、著者本テーブル群を選択し、本テーブルを唯一の関連のテーブルとして再び定める。次に、段階２５３は、ｔＩｂＢＯＯＫ．ＢＯＯＫＩＤ及びｔｂｌＢＯＯＫ．ＬＩＳＴを含むリストを抽出し、従って、ＲＩＤとして使用されない非基本キー属性が１つだけあり、従って、ＰＩＲ＝１*１／９である。]
[0135] 第３の反復で、段階２４２は、州コードを選択する。段階２５３は、２つの属性、すなわち、ｔｂｌＳＴＡＴＥ．ＳＴＡＴＥＣＯＤＥ属性及びｔｂｌＳＴＡＴＥ．ＳＴＡＴＥＩＤ属性のリストを抽出する。この場合、ＰＩＲ＝１*１／２である。]
[0136] 選択度なしの場合、分析の各々のＰＩＲ値は、州テーブル群分析に対しては０．５、顧客テーブル群に対しては０．１１、及び著者テーブル群に対しては０．４５である。閾値が約０．４に設定されると仮定すると、顧客−注文−品目群の分析により、ＣＵＳＴＯＭＥＲＩＤ属性、ｆｋＣＵＳＴＯＭＥＲＩＤ属性、ＯＲＤＥＲＩＤ属性、ｆｋＢＯＯＫＩＤ属性、及びｆｋＳＴＡＴＥＩＤ属性の値を有するｒｅｓｕｌｔｓｅｔが生成される。このｒｅｓｕｌｔｓｅｔは、品目テーブル内の品目総数に等しい横列数を有する。]
[0137] 著者テーブル群のＰＩＲ値は、その閾値を下回り、段階２６０は、本テーブルに関連する非結合述語がないので何の影響も与えず、従って、段階２６１は、各々が本テーブル内の全ての本を再び識別するＬＩＳＴ価格属性に対して垂直縦列容器の走査を識別することにより、オプション３を選択する。同様に、州コードｒｅｓｕｌｔｓｅｔは、ＳＴＡＴＥＣＯＤＥ属性に対して垂直縦列容器から計算され、ＳＴＡＴＥＣＯＤＥ属性は、ＳＴＡＴＥＩＤ及びＳＴＡＴＥＣＯＤＥの値を論理的に含み、かつ各州に対して１つの横列を含む。]
[0138] 図１６は、本発明により開発された図５Ａの問い合わせに関する問い合わせ計画２８０を示している。段階２８１では、ｔｂｌＳＴＡＴＥ．ＳＴＡＴＥＣＯＤＥ垂直容器から結果組を生成する。段階２８２は、顧客テーブルからのｆｋＳＴＡＴＥＩＤ属性、品目テーブルからのｆｋＢＯＯＫＩＤ属性、及び品目テーブルからのＳＡＬＥ属性を含むｒｅｓｕｌｔｓｅｔ２８３を生成する顧客−注文−品目容器内の全てのクラスターの走査を表している。結合演算２８４では、段階２８３の射影の各横列が州コードを含むｒｅｓｕｌｔｓｅｔを生成する。] 図１６ 図５Ａ
[0139] 次に、システムは、段階２８５で、その暗黙のＢＯＯＫＩＤ属性でｔｂｌＢＯＯＫ．ＬＩＳＴ垂直容器を検索する。段階２８６は、段階２８４の中間ｒｅｓｕｌｔｓｅｔの品目テーブルのｆｋＢＯＯＫＩＤ属性と結合する。段階２８７は、ｒｅｓｕｌｔｓｅｔを州コード、価格、及び販売の属性を含むｒｅｓｕｌｔｓｅｔに変換する。段階２８８は、図５Ｂの段階８８と同様に、州コードに基づいて集約を供給し、段階２８９の結果を生成する。] 図５Ｂ
[0140] 比較として、図５Ｂの従来技術方法を使用して図５Ａに示す問い合わせを処理するには、４回の結合演算が必要である。本発明によりかつ図１６に示すように、この数は、フェッチされるデータ容量及びランダムアクセスの回数を最小にするために、適切な場合には、縦列容器を用いて更に改善される２回の結合演算に低減される。] 図１６ 図５Ａ 図５Ｂ
[0141] これらの例により、複数のデータストアユニットを使用する際の利点の理解が可能である。従来技術の方法は、テーブル構造の横列を検索するか、又は述語を使用して縦列をフィルタリングする。しかし、結合演算は依然として実行する必要がある。索引を付されない縦列をフィルタリングするためには、テーブル全体を走査する必要がある。本発明を含むシステムは、データの複数のコピーを格納する。この特定の例においては、水平データストアユニット内の１つのコピーは、共にクラスター化された関連の横列を格納し、従って、テーブル間の群結合コスト及び異なる横列へのランダムアクセスが排除される。第２のデータストアユニット内に順番に縦列を格納することができ、特定の縦列の検索が非常に効率的なものになる。これらの手法では、問い合わせ処理を最適化する問い合わせによるあらゆるアクションに向けて、クラスターのようなできるだけ多くの関連データをユニット内で組み合わせる。データのサイズ、データモデルの複雑性、及び問い合わせの複雑性が増加する時に、この設計における固有の利点により、実行の漸進的な効率化が可能である。]
[0142] データベース更新
本発明は、更新イベントに応答してデータベースを更新する直接的方法を用いる。図１７に示すように、ルーチン２９０は、各更新イベントを処理する。最初に、図６内の変更ログ１０５内に各データ更新問い合わせに関連のデータを格納する。段階２９１は、データ変化を必要とし、かつ「データ変更ｘ」と指定される変更ログエントリを検索する。段階２９２では、その有効性を検査する。段階２９３では、その変更が有効であるか否かを判断する。有効ではない場合、制御は、あらゆる付加的な更新を終了するロールバックルーチン２８４に移る。] 図１７ 図６
[0143] データ変化が有効である場合、段階２９３は、段階２９５に移って、第１次元データストアユニット１０６又は第２次元データストアユニット１０７を選択する。段階２９６では、選択されたデータストアユニットへのデータ変更を適用する。処理は、段階２９６が選択されたデータストアにより変わる点を除き、従来技術のものと類似である。すなわち、第１次元データストア１０６が選択され、これが新しい顧客のような新しいデータを表す場合、段階２９６は、顧客注文品目及びあらゆる品目エントリを含むその顧客に関するクラスターを形成する必要がある。]
[0144] 変化の適用が成功しなかった場合、段階３００は、制御をロールバックルーチン２９４に移す。成功した場合、段階３０１は、いずれかの付加的なデータストアユニットを更新する必要があるか否かを判断する。従って、これが段階２９５〜３０１を含むループの第１の反復の終了である場合、制御は、段階２９５に戻って、第２次元データストアユニット１０７を選択する。この場合、データは、各々の適切な縦列容器の終了に追加されることによって適用される。ここでもまた、第２次元データストアユニット１０７の変更が成功であった場合、段階３００は、段階３０１に戻る。]
[0145] これが第２の反復である場合、段階３０１は、制御を段階３０２に移し、いずれかの付加的な変化がデータ変更ログ１０５内に残っているか否かを判断する。全てのデータ変更が問題なく完了した場合、段階３０３は、変更を行って処理２９０を終了させる。]
[0146] ＸＭＬシステム
本発明を組み込むデータベースシステムは、ＸＭＬデータの記憶及び取り出しに対して、特に、「ＸＭＬスキーマ」又はＸＳＤとしても知られる公知のＸＭＬデータモデルに基づくＸＭＬデータに対して容易に適応される。図１８は、図９の顧客−注文−品目テーブル群１６５に関するこのようなＸＭＬスキーマを開示する。以下に明らかになるように、ＸＭＬスキーマは、属性、注文、及び品目を含む顧客に関連の全ての情報を定め、図９内のデータ辞書１０２から直接に抽出することができ、マッピングが不要である。] 図１８ 図９
[0147] 図７内の容器１１０に対応する「顧客容器」要素３１０の次に来るのは、それぞれの属性と共にそれぞれ図９内の顧客テーブル３６Ｄ、注文テーブル３７Ｄ、及び品目テーブル４０Ｄに対応する顧客要素３１３、順序要素３１５、及び品目要素３１７である。ＸＭＬスキーマ内の要素の順序は、ルートテーブル及び定義関係で図９内のデータ辞書１０２内に形成された順序に従う。より具体的には、システムは、３１３での顧客テーブルに参照を含むことによって構造を識別及び確立する。これに続いて、図１内の顧客テーブル３６に関する属性を定める一連の要素名称演算３１４及び３１９が来る。次に、システムは、３１５で注文テーブルを識別し、図１内の注文テーブル３７に関する属性に対応する様々な要素３１６を確立する。それに続く文章３１７は、品目テーブル及び属性３１８を定めるものである。当業者に明らかなように、図１８のＸＭＬスキーマは、全体的又は部分的に関わらず、あらゆる関係の変化、又はテーブルの追加、削除、又は修正、及び属性の追加、削除、又は修正を処理するように容易に適応される。] 図１ 図１８ 図７ 図９
[0148] 図１９は、図１８のＸＭＬスキーマによる顧客−注文−品目テーブル群に関する図２のデータのサンプルを示している。具体的には、図１９は、図１２Ｃ及び図１２Ｄに詳細に示すように、図１２の「ＡＤＡＭＡＰＰＬＥ」１９４に関する水平クラスターに対応するようなＸＭＬデータ１９４Ａを開示するものである。ブロック２００Ａは、顧客データを含むクラスター１９４内のクラスター横列２００に対応しており、この場合、顧客は、「Ａｄａｍ Ａｐｐｌｅ」である。その後にあるのは、クラスター横列２０１に対応する注文を識別する別のブロック２０１Ａである。ブロック２０３Ａ及び２０４Ａは、２０１Ａの注文に属する２つの品目を識別する。] 図１２ 図１２Ｃ 図１２Ｄ 図１８ 図１９ 図２
[0149] この場合にかつ図１２に示すように、「Ａｄａｍ Ａｐｐｌｅ」は、２つの注文を有する。従って、ブロック２０２Ａは、第２の注文を識別し、ブロック２０５Ａは、この第２の注文に関連する単一の品目を識別する。クラスター１９５に対応する顧客クラスター「Ｂｏｎｎｉｅ Ｂｉｒｄ」１９５ＡのＸＭＬデータが次にあり、参考としてのみ示されている。従って、図１９のＸＭＬデータは、全ての顧客クラスターを含む容器１１０内のデータに相当する。同様に、他のテーブル群は、データ辞書１５０内の情報及び水平容器内のデータから導出されたＸＭＬスキーマ及びＸＭＬデータ文書で表される。] 図１２ 図１９
[0150] 逆に、ＸＭＬスキーマがあれば、データストアユニットに関する対応するデータモデル１５０及びデータ構造を構築することができる。このような場合、図１０Ａの段階１５３は、グループ分け階層がＸＭＬスキーマの一部として予め定められているので冗長になる。従って、図１１Ａ〜図１１Ｅにおいて追跡される図１ＯＢ内のアルゴリズムは、不要になる。ＸＭＬスキーマは、クラスター内で直接定めることができる構造を定める。従って、ＸＭＬデータは、同等の構造を含むのでクラスターに直接取り込むことができる。実行時に、システムに示されるＸＭＬ問い合わせは、ＳＱＬ問い合わせに向けて開発された方法でかつ両方のデータストアユニットで内部的に処理され、結果は、ＸＭＬデータとして戻される。] 図１０Ａ 図１１Ａ 図１１Ｂ 図１１Ｃ 図１１Ｄ 図１１Ｅ 図１ＯＢ
[0151] 要約すると、本発明により構築されたデータベース管理システムは、属性を定める縦列と、値、関連の基本キーと外部キー間のリンク、及び問い合わせ、一般的に例えば図１に示すようなＳＱＬ問い合わせを格納する横列とで組織化された従来の論理テーブル図に適合するものである。データベース管理システムは、例えば、図６に示すような異なるデータストアから及びそこへデータを転送するために各問い合わせを処理する。第１のデータストアは、第１のスキーマに従って、第２のデータストアは第２のスキーマに従って完全なデータベースを格納する。すなわち、本発明の目的により、データベースは、異なるスキーマに従ってではあるが、データベースの冗長なコピーを有する。] 図１ 図６
[0152] 第１のデータストアでデータを転送することは、モデル内の論理テーブルを図１に示す図のようにテーブル群に変換することを含む。各テーブル群は、例えば、図１０Ｂ及び図１１Ａ〜図１１Ｅに示すように、ルートテーブル、及びルートテーブルと直接、間接に関わらず結合された他の論理テーブルのアレイを含む。第１のデータストアは、例えば、図７に示すように、容器内の１つの使用量パターンに従ってデータを格納する。各容器は、対応するルートテーブル内の各横列、及びそのテーブル群に関してルートテーブルに直接、間接に関わらず結合されているテーブルのアレイの全ての横列に対する少なくとも１つの識別されたクラスターを含む。各クラスター内のデータは、ルート論理テーブルの横列からのデータ、及びルートテーブル横列内のデータと結合されているテーブル群内の他の論理テーブルからの全てのデータを含む。第２のデータストアは、例えば、図８に示すように、複数の縦列容器内の第２の使用量パターンに従ってデータを格納する。テーブルと属性の１つとの各組合せに対して１つの縦列容器がある。] 図１ 図１０Ｂ 図１１Ａ 図１１Ｂ 図１１Ｃ 図１１Ｄ 図１１Ｅ 図７ 図８
[0153] 各クラスター横列内のデータは、第１のデータストア内に順番に格納され、論理テーブル中の対応する縦列に関する各縦列容器内の属性値が順番に格納される。本明細書で開示されているようなスキーマに従ってデータを順番に格納することにより、２つの利点が得られる。第１のデータストア内のデータは、特に、アクセスがルートテーブル内の単一の横列又は限られた数の横列に制限される場合に、ＯＬＴＰ問い合わせにより表される第１の使用量パターンに基づいてデータを転送するように最適化される。第２のデータストア内のデータは、いくつかの縦列のみを通常選択するＯＬＡＰ問い合わせとの関連に従って、第２の使用量パターンに基づいてデータを転送するように最適化される。ランダムではなく、順番にデータを選択することによって収量が改善するが、その理由は、選択されたデータを順番に検索することができるからである。]
[0154] データベース管理システムは、例えば、図１４〜図１４Ｃに示すようにｒｅｓｕｌｔｓｅｔを検索する複数の手順を含む。制御装置は、各テーブル群及びアクセスされることになる推定されたテーブル群の部分に関する要請された情報に基づいて、ｒｅｓｕｌｔｓｅｔの受信を最大に利用する複数の手順のうちの１つを選択する。それによって最終ｒｅｓｕｌｔｓｅｔを取得するために問い合わせを終了するのに必要とされる時間を最小にすることによって収量が改善する。論理データベース内の表された全ての結合演算のうちの各テーブル群に関するｒｅｓｕｌｔｓｅｔ間の結合のみが必要とされる。それによって結合演算の回数が大幅に低減され、更に、応答時間及び収量が改善する。] 図１４ 図１４Ａ 図１４Ｂ 図１４Ｃ
[0155] 本発明の他の特徴により、付加的な収量に関する利点が得られる。例えば、問い合わせ計画に表されると考えられる正確なシーケンスは、問い合わせ処理中に動的に判断される。図１４Ｂに示すように、ｒｅｓｕｌｔｓｅｔを取得するための処理は、各テーブル群に関する分析終了後に直ちに始まる。図１４Ｃに示すように、戻された中間ｒｅｓｕｌｔｓｅｔは、サイズ別に順序付けられている。それによって異なるテーブル群との関係を確立する結合の実行が最適化される。] 図１４Ｂ 図１４Ｃ
[0156] データベース管理システムはまた、非常に複雑な論理データベース表現を処理するようになっており、かつＳＱＬ問い合わせのような標準問い合わせ言語とのインタフェースを有するようになっている。更にかつ図１８及び図１９に示すように、システムはまた、データ構造及びデータ変更を定めるためにＸＭＬとのインタフェースを有する。] 図１８ 図１９
[0157] 本発明をある一定の実施形態に関して開示した。本発明から逸脱することなく多くの修正を開示した装置に行うことができることが明らかであろう。例えば、本発明の開示は、２つの特定のストレージユニットに関するデータ構造を説明したものである。本発明は、他のデータ構造に等しく適用可能である。当業者に明らかなように、ストレージユニットの各々又は両方に対してデータの変化を要求するイベントに対する応答は修正することができる。ＳＱＬ問い合わせに対する応答の本発明の開示は、個々の問い合わせが処理されるシーケンスにおいて、かつ１つ又はそれよりも多くのオプションの追加、削除、又は修正による検索オプションの修正において異なる内部処理及び修正を提供するために修正することができる。]
[0158] １００データベース管理システム
１０１ 問い合わせ構文解析プログラム
１０２データ辞書
１０３ 問い合わせプロセッサ
１０５ 変更ログ]

权利要求:

請求項1
少なくとも１つのテーブル群を含む論理データベースモデルのデータを格納するためのデータベースストレージ手段を含むデータベース管理システムであって、各テーブル群が、１つのルートテーブル及びそれに関連する少なくとも１つの他のテーブルを含み、各論理テーブルが、属性の縦列及びデータの横列を有するように特徴付けられており、データベースストレージ手段が、Ａ）メモリ位置の各々が、ルートテーブルの１つの横列からの全てデータと、そのテーブル群内の他のテーブルからの全ての関連データとを含み、その１つのルートテーブル横列の関連データが、それによってそのルートテーブル横列及び他の関連テーブル内のその関連の横列における全てのデータへの順次アクセスを可能にする第１の次元の複数のメモリ位置で、全てのデータをデータベースに格納するための第１のデータストア手段、及びＢ）各メモリ位置が、前記データベース内の前記属性の１つからの全てのデータと全ての対応する値とを含み、それによって各属性内の該データへの順次アクセスを可能にする第２の次元の複数のメモリ位置で、全てのデータを該データベースに格納するための第２のデータストア手段、を含む、ことを特徴とするシステム。
請求項2
前記第１及び第２のデータストア手段における前記メモリ位置の各々が、隣接するメモリ位置を含むことを特徴とする請求項１に記載のシステム。
請求項3
前記テーブル群の異なるものにおけるテーブル間の関係を識別する論理データベースモデル辞書からの情報でポピュレートされたデータ辞書を更に含み、前記第１のデータストア手段における前記メモリ位置は、前記関係における前記ルートテーブル及び他のテーブルの１つの横列に関連するデータを格納し、それによってそのデータ構造が、該関係に従ってテーブルを固有にリンクさせ、それによってそのような関係がアクセスされる度に結合演算を処理する必要性を排除する、ことを特徴とする請求項１に記載のシステム。
請求項4
各テーブル群に対する前記データは、クラスター及びクラスター横列を含む容器に格納され、ｉ）クラスター横列が、前記テーブル群の前記テーブルにおける各横列に対してクラスター横列識別を有するヘッダとデータに対する本体とを含み、ｉｉ）クラスターが、前記ルートテーブルにおける１つの横列に対するクラスター横列と、前記テーブル群の各関連テーブルにおける対応する横列とを含み、かつｉｉｉ）容器が、前記テーブル群に対する全ての前記クラスターを含む、ことを特徴とする請求項１に記載のシステム。
請求項5
前記クラスター横列識別は、前記テーブル群における前記クラスターと対応するテーブルとに対する識別子を含むことを特徴とする請求項４に記載のシステム。
請求項6
各テーブルが、そこにある各横列に対する固有の識別子を含み、各前記クラスター識別子は、前記ルートテーブルに対する該固有の識別子の値を含み、各クラスター横列識別子が、該テーブルにおける該横列に対する該固有の識別子を含むことを特徴とする請求項５に記載のシステム。
請求項7
各ヘッダが、クラスター横列に関連する前記論理データベース内のテーブルを更に識別することを特徴とする請求項５に記載のシステム。
請求項8
各ヘッダが、クラスター横列における各属性及びそのクラスター横列に該属性が存在するか否かを識別するための属性識別子を更に含むことを特徴とする請求項５に記載のシステム。
請求項9
各ヘッダが、前記クラスター横列の前記本体における属性値に対するポインタを更に含むことを特徴とする請求項５に記載のシステム。
請求項10
各クラスター横列内の前記情報は、隣接メモリ位置に格納されることを特徴とする請求項５に記載のシステム。
請求項11
各クラスター内の前記情報は、隣接メモリ位置に格納されることを特徴とする請求項１０に記載のシステム。
請求項12
各容器内の前記情報は、隣接メモリ位置に格納されることを特徴とする請求項１１に記載のシステム。
請求項13
前記第２のデータストア手段は、テーブル及び属性の各組合せに対する縦列容器を含み、各縦列容器が、ヘッダ及び縦列データを含むことを特徴とする請求項２に記載のシステム。
請求項14
各ヘッダが、論理テーブル及びそこにある１つの属性の識別を含むことを特徴とする請求項１３に記載のシステム。
請求項15
前記容器の識別が、テーブル名と前記属性の名称との連結によって構成されることを特徴とする請求項１４に記載のシステム。
請求項16
各ヘッダが、その属性に対するデータの構造を識別する縦列タイプ値を更に含むことを特徴とする請求項１４に記載のシステム。
請求項17
前記縦列タイプ値は、コードテーブルを識別し、前記ヘッダは、各コードに対して前記値を識別するコードテーブルフィールドを更に含むことを特徴とする請求項１６に記載のシステム。
請求項18
各前記縦列タイプ値は、可変長を有する値を識別し、前記ヘッダは、前記縦列データの位置に対するポインタを有する属性ストライド位置ベクトルを更に含むことを特徴とする請求項に記載のシステム。
請求項19
各ヘッダが、前記縦列容器におけるデータ値の性質を示すデータタイプフィールドを更に含むことを特徴とする請求項１４に記載のシステム。
請求項20
各ヘッダが、前記縦列データ内のある一定の位置に指す属性ストライド位置ベクトルを更に含むことを特徴とする請求項１４に記載のシステム。
請求項21
異なる関係にあるテーブルとデータ辞書とを有する論理データベースに収容されたデータのためのデータ構造を発生させる方法であって、Ａ）各テーブル群に対してルートテーブルとそれに関連するテーブルとを含むデータ辞書内のデータに基づいて論理データベース内のテーブルからテーブル群を形成する段階、Ｂ）複数のメモリ位置の各々が、前記ルートテーブルの１つの横列からの全てのデータと、その関連テーブルからの関連データとを含み、それによってそのルートテーブル横列及び関連のテーブル横列における全ての該データへの順次アクセスを可能にする第１の次元で、各テーブル群に対してデータベースに対するデータを格納するためのデータストアユニットを作成する段階、及びＣ）各メモリ位置が、前記データベース内の属性からの全ての前記データと全ての対応する値とを含み、それによって各属性メモリ位置における該データへの順次アクセスを可能にする第２の次元の複数のメモリ位置で、前記テーブル群における各テーブル及び属性に対して、該データベースを格納するための別のデータストアユニットを作成する段階、を含むことを特徴とする方法。
請求項22
テーブルの各々が縦列内の属性及び横列内のデータを含み、かつ異なる関係にあるルートテーブル及び関連テーブルと、第１の次元でデータストアユニットに格納されたデータベースにおける各テーブル及びそのテーブルに対するテーブル群を識別するデータ辞書とを有する論理データベースへの問い合わせに応答する方法であって、複数のメモリ位置の各々が、ルートテーブルの１つの横列からの全てのデータと、その関連テーブルからの関連データとを含み、かつ第２の次元の複数のメモリ位置の別のデータストアユニットに格納され、各メモリ位置が、データベース内の属性の１つからの全てのデータと全ての対応する値とを含み、問い合わせへの応答が、各テーブル群に対して、Ａ）前記問い合わせにおけるテーブル群及び前記テーブルを識別する段階、Ｂ）データ辞書によって提供された前記テーブル群内の前記テーブルを前記識別された問い合わせテーブルに対して比較することにより、前記問い合わせを構文解析する段階、Ｃ）前記データベースと前記問い合わせとに共通のテーブルに収容された該問い合わせ内の属性のリストを抽出する段階、Ｄ）属性の前記抽出されたリストに応答して複数の処理オプションの１つを識別する段階、Ｅ）前記テーブル群に関連した前記問い合わせの部分を満足する中間ｒｅｓｕｌｔｓｅｔ内のデータを前記データベースから取得するために前記選択されたオプションを処理する段階、及びＦ）前記問い合わせを満足する最終ｒｅｓｕｌｔｓｅｔを取得するために前記中間ｒｅｓｕｌｔｓｅｔを組み合わせる段階、を含む、ことを特徴とする方法。